Regional Scrum Gathering Tokyo 2017（2日目） 参加してきた
2017/01/12, 13 の2日間にかけて開催された
Regional Scrum Gathering Tokyo 2017 2日目の参加レポートというか自分用メモです。
1日目の記事はこちら
1日目に引き続き、酒飲んで帰宅した直後に書いてるので色々見にくいところがあるかもですm(_ _)m
スライドは公開され次第、更新していく感じで
セッション一覧、スライドなどはこちら
ハッシュタグ ： #RSGT2017
togetter：https://togetter.com/li/1069966
参加したセッション一覧
- Agile journey through the decade - あるエバンジェリストが歩んだアジャイル近代史
- 日経電子版 穴のあいたバケツ開発
- Scrum / DevOps の導入を加速させるグローバルマインドセット
- 缶詰屋さんの課題解決にスクラムを使ってみた
- 結果的にスクラムになってる！なのがいいと思う！
- 最短で成果を上げる！強いスクラムチームの作り方
- Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法
Agile journey through the decade - あるエバンジェリストが歩んだアジャイル近代史
長沢さん @tnagasawa
スライド公開されてない模様
メモ
ハッシュタグ付けてtweetするとリアルタイムで流れていてそっちに気が取られたｗｗ
Agileが浸透していなかった時代
→どちらかというと「なんか宗教じみてたり、現実と合ってないんじゃない？？」とかで選定条件から外されてた
コンサルからエバンジェリストになって
コンサルなので契約の期間があって、その期間が縁の切れ目になることが多い
終了後、しばらくしてから聞いても「上手くいかなかった」の声が多かった
MSのエバンジェリストをやっているとMSの製品を使ってる人、コミュニティの人にしか会えない
→そこに壁があるなら壊そうと考えた
Agileを使えばその壁が壊せそうだし、MSという名前を使えないかと考えた
企画書出して通過
→社内の人とはできないのでソラコムの玉川さんに協力を求めた
→IBMとMSのエバンジェリスト2人が登壇（当時はそんなことがなかった）
暗黙のルール（サイトにコミュニティの情報とか書いてはいけない）を明確なルールじゃないから！ってことで破った
「実践している人たちの事例を広める、 その場 を作ったに過ぎない」
イベント主催「AgileDay」 #msagile
色々やったけどかなりの傷を受けた
味方はいなかったけどやらせてくれた
「ソフトウェア開発は、そもそも難しいんだよ」
お客さんがAgileでやろうと言っていたとしても足並みが揃っていないとダメ
現場とビジネスが同じ場所を見ていなければアジャイルは進まない、コンセンサスを取ることが重要
同じゴールを見ましょう
現場とビジネスの足並みは揃ってきた
- バズワード化してきたけど、バズワードに出会ったら、現場を見つめる。現場を信じる
- 文化を悲観するより、今ある問題と向き合う
- 文化とは過去のものが承認されてできたもの。あまり重要ではない。
- 今ある問題に向き合えばそれが未来の文化になる
Q&A
Q : 矢を受けた時にどうやってストレスマネジメントしてましたか
A : 矢を受けてないと思うことが一番
後は、1人で抱え込まないこと。
仕事でべったりしてる仲間ではなく、コミュニティの仲間などに愚痴ったり
日経電子版 穴のあいたバケツ開発
武市さん
スライド公開されてない模様
メモ
穴のあいたバケツに多く水を入れたいプロダクト
- イケてるバケツを開発できるチームを作る（内製化）
今までの開発
いちいち遅くてデカイ
→シャアボタンを追加に2週間開発 + 申請期間
おそすぎる、フィードバック得られない
アジャイル開発で小さく速く届ける
→内製化 まずはスモールスタートで一番ユーザに近い画面を内製化 - バケツを大きくする
全面リニューアル
スクラッチで全て内製化
社員でも自分事化出来ない人はいらない - バケツの穴を塞ぐ
リテンションとは小さなカイゼンの繰り返し
新機能を追加するわけではない
Scrum / DevOps の導入を加速させるグローバルマインドセット
牛尾さん @sandayuu ロッシェルさん @JICRochelle
スライドはこちら
メモ
アメリカの後追い感あるからスピード遅いからそういうのを速くしたい
AgileかWFとかで議論している場合じゃねえんだよ!!
DevOpsはAgileの上に成り立ってるけど
日本文化の上にAgileを載せようとするとなんか噛み合わない
Agileってアメリカの人達が作ってきたものだから西洋文化入ってますよね？？
別に日本人が能力的に劣っているとかではない、西洋文化をインストールしてやろう
8つの文化習慣を西洋文化ではどういう背景でなっているのかを理解すればいい
文化を変えるのは大変とか言うけどScrumインストールは文化を変えてるのと変わらない
テクニックだけをインストールするんではなくて、マインドセットもインストール
「This is not Agile, Wa(和)-gile」
気付かぬうちに日本のやり方になっているから本来の姿を理解する
日本の文化で育っているので「違い」に気付けないからまずは理解
周囲の巻き込みは最初から行っていく
最初はうまくいかないけど、やってみること
8つの習慣を理解する
- 優先順位をつける
日本：順位付けするけど、可能な限り全て終わらせる
米国：5つあったら1番上だけやって、後はやらない - 会議の違い
日本：会議の前後に準備する
会議で寝る人もたまにいる
会議の後で実行に移る
米国：準備しない
米国では喋らない人がいない
会議の時間で何とか済まそうとする - 失敗した時
日本：怒られる、部下が失敗することに対して恐れるようになってしまう
米国：感情的になるのは御法度で失敗したことからの学びが重要
フィードバックが喜ばれる - プロジェクトが中止になった時
日本：プロジェクト開始後に文句を言う
でも計画したし、予算も取ってるから意味ないけどやってしまう
米国：変化に対応するのが大事だと思うので、意味ないならやらない（とめる）
何か中止になった時も上手く行った時と同じようなパーティをするところもある - サーヴァントリーダシップ
日本：指示するだけのことが多い
米国：一緒になって先導して実行する - チームワーク
みんなが助け合って、状況の変化にフレキシブルに対応していくこと
リーダっぽい人がいてみんなその人に聞いてとかではない - 従業員への信頼
アメリカビューだと全員を子供扱いしていると見える
プールで強制的な休憩時間があるが、アメリカでは絶対にない
ルールで縛りたがるし、日本はハンコ多すぎてスタンプラリーっぽいよね
そんなのは自己責任で自主性に任せよう - 「許可を求めるな、謝罪せよ」
自分で考えて、いいと思ったんならやってしまえよっていう常識を語っているだけ - 自信を持って他人を助ける
何か知ってないと語れない、やれないと思いがちだけどその場で一緒に考えようぜ
準備しないことを恐れない - 顧客
大事なのは顧客とコラボレーションできるかどうか
うまくするためには顧客を教育する
日本では顧客がプロダクトを見下す
遠慮してしまいがちで、行動する前に躊躇して辞めてしまうことが多い
缶詰屋さんの課題解決にスクラムを使ってみた
オオトモさん @toshiotm
スライドはこちら
メモ
急に会社辞めて、缶詰大学に通いだした人のお店
かなりやること多くて全く手が回ってなかった
問題点
- 中に入り込みすぎて客観的に見れなくなった
- 目の前に有ることに必死で、その場しのぎの判断をしてしまう
これらってソフトウェア開発の場面でもよくあるよね
課題1
ユーザストーリマッピングを「サクセスストーリーマッピング」に変えて使おうってなった
問題と実現したいことを書き出して時間軸にそって並べてみる
実現したいことを達成した結果を定量的な数字で洗い出す
課題2
従業員に対して要求は出すけど実現は自分達でやってほしかった
ってことで「受け入れ条件」を書く
サクセスストーリーマッピングからバックログを作成
作成したサクセスストーリーマッピングも将来のビジョン、ゴールの共有ということで従業員に見せる
スプリントプランニングでタスクだしして、接客していない時にタスクをこなす
初日のバイトの子が一緒になってプランニングやってたりしてて良い！！！
ソフトウェア開発以外でもスクラムやってるの初めて見た
今後の動向ってのも見てみたい
結果的にスクラムになってる！なのがいいと思う！
しいば さん @bufferings
スライドはこちら
メモ
どうやって 組織の中で スクラムを始めるのかを考えてみる
答え スクラムをはじめない というのが出てきた
例1
スクラム導入しようって言われたけど
とりあえずGood&Moyattoで問題聞いて、洗い出して問題を解決しようってことにした
問題の解決策としてスクラムのプラクティスとは言わずに実施
まずは、1週間だけと言って開始
2週間後にはもうかなりスクラムっぽくなっていた
スクラムやろうとしてやると スクラムお化け が出て来る
問題解決をしようとしてコツコツやっていくとみんな受け入れやすい
例2
スクラムを始めていてスクラムお化けに取り憑かれているというチームから相談
一旦スクラム忘れようぜ！！
上手く行ってない因果ループを見つけて、どこからカイゼンしてもいい
どっか対処しやすいところからやっていけば全部ひっくり返しやすくなる
スクラムやろうとするのではなく、実感している問題から始めてチームに合ったやり方で1歩ずつ
問題解決の道標としてスクラムを使えば組織に合ったスクラムになる
しいば さんからの質問
皆さんのスクラムやろうとしている根本的な問題はどこですか？？
最短で成果を上げる！強いスクラムチームの作り方
松浦さん @ayaya1024
スライド公開されてない模様
メモ
最短で成果を上げる秘訣 KYPAS
- K 期待を確認する
期待マネジメント - Y まずはやってみる
小さく始める
本一冊あたり3年分の学びを得ることができる - P すばやいPDCAをまわす
すばやいフィードバックを
フィードバックをもらったら、感謝を伝えて腹落ちするのが大切 - A プロのアスリート
休むのも仕事
自ら積極的に相談しに行く - S 強いスクラムチームを作る
社内だけでなく社外も巻き込む
強いスクラムチームの作り方
社内実践事例「イノベーションサミット」
リーンスタートアップ手法を用いて農業ICTで活動中
- ネーミングで共通認識をとる
- 小さな成果を積み上げる
- できるペースでできる範囲で
- 少数精鋭のチーム（なんでもリリースできる体制）を作る
スクラムをやろうとするのではなく、スクラムは手段
課題があって、その問題を解決していく、自然とスクラムになるのが良い
正解は1つではない
他人を変えるのは難しいのでまずは、自分でカイゼンしていくことが大切
スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法
吉羽さん @ryuzee
スライドはこちら
メモ
- いつも完成しないスプリント
- 改善したからベロシティが上がるとは限らない
次のスプリントの成果を参考にするのならOK - 最初のスプリントの見積もりなんてあてにならない
→プロジェクトの最初に色々なものをコミットメントなんてできない - 祝日はキャパシティから引っこ抜く
- リズムが大事、毎回同じ会議室でスクラムイベントとか
- 1スプリント自分がやったことないタスクをこなす期間を用意
- 改善したからベロシティが上がるとは限らない
- 機能不全なプロダクトオーナー
兼任はしてもいいけど、クリティカルな部分を持たないことを強くオススメする - 不十分なふりかえり
- 不安定な品質
スクラムはテクニカルプラクティスを定めてないけどやらなくていいわけではない！！ - 機能しないデイリースクラム
書けないペンが残っている開発チームはダメ - 教育不足
ルールを知らずにゲームをやるのか？？
感想
なんとなーくだけど組織って話が多かった気がする
スクラムをやろうとすると多分組織に何かしら問題があるってのがみんなの共通認識なのかな？？
とりあえず殴り書きのメモだし、まだ自分の中に落とし込めてない話も色々あるので復習とか聴けなかったセッションのスライド見たりしたいところ
楽しい2日間でした！！！ありがとうございました！！
Regional Scrum Gathering Tokyo 2017（1日目） 参加してきた
2017/01/12, 13 の2日間にかけて開催されている
Regional Scrum Gathering Tokyo 2017 1日目の参加レポートというか自分用メモです。
酒飲んで帰宅した直後に書いてるので色々見にくいところがあるかもですm(_ _)m
スライドは公開され次第、更新していく感じで
あとKeynoteは朝仕事してたので、参加してないです。。。
（決して寝坊したとかそいうやつではない。。。）
セッション一覧、スライドなどはこちら
ハッシュタグ ： #RSGT2017
togetter：https://togetter.com/li/1069660
参加したセッション一覧
- シン・未来会議 - スクラムチームを支える組織づくり -
- つらい問題に出会ったら
- ゲーム開発を盛り上げる技術とチームを支え続ける原動力
- 学生がチーム開発のメンタリングを改善したひと夏の話
- エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史 -
- アジャイル・メトリクス実践ガイド
シン・未来会議 - スクラムチームを支える組織づくり -
及部さん OYB48 (@TAKAKING22) | Twitter
スライドはこちら
メモ
- 組織は変わるべきか
トレンドの移り変わりはかなり激しいし、変化のスピードの加速
生き残るためには変化とスピードが重要になってきた
スピード感がでてなさそうなもの- 年間計画
- 評価制度
- 採用サイクル
シン・未来会議
最初はエンジニアリーダが集まってのふりかえり
でも自分達ではどうしようもないProblem（人・モノ・カネ）がでてきた
→ 組織としてのふりかえりが必要なんじゃない？？
因果関係図を創った
→ 問題の見える化
エンジニアのモチベーション低下の因果ループを見つけて、解決しやすそうな突破口を見つけた
ってことで シン・未来会議 開催（詳しくはスライド参照）
「うちは〇〇だから無理」とか「組織はこうあるべき」とかは違うでしょ
変えるのか変わらないのか、何を優先するのかは「自分達」で決める
これを飛ばしていっては、組織づくりなんてできないよ
いちばん大事なのはシン・未来会議の後、そのまま飲みに行くこと
つらい問題に出会ったら
開原さん kaihara (@155gta) | Twitter
スライド公開されてない模様
メモ
つらい問題に合っている時に自分を立て直す対話という本を進められた
- ロジカルに解決できない問題もある
→ロジカルは切れ味がよすぎる - 全員視点が違うので100％分かり合えることなんてない
→対話を通してお互いに理解し合えるポイントを見つけていく
智慧の車座 で対話をしていった（詳しくは本に書いてあるらしい）
- 自分の問題を自分で語ってみると自分が気付いてなかった問題が見つかることがある
- 自分主体の物語に変えていくことが出来る
対話しましょうと誘うのではなく、ワークショップしましょうといって開催した
飲みに行こうかってなってもただ愚痴になったり、別の話になったりするけどこれなら 短時間で深い本気話 になりやすい
仕事上近い人だと、問題解決脳になってしまってこうすればいいじゃんになってしまうので、仕事上関わりが薄い人達で行うことをお勧め
ゲーム開発を盛り上げる技術とチームを支え続ける原動力
田口さん Ta╭( ･ㅂ･)و ｸﾞｯ chi (@masahirotaguchi) | Twitter
スライド公開されてない模様
メモ
自分のパフォーマンスを上げてもたかが知れてるが、チームのパフォーマンスを上げたほうがユーザに早くいいゲームが届けられる
みんなの愛の力を価値に!!!
ゲーム業界は他のソフトウェア業界よりもプロダクトを愛している
ただ愛の表現方法が、残業、休日出勤、徹夜という。。。
愛している故に、廊下で殴り合い
現場は既に盛り上がっているが、
拳で語るのではなく、 安全な場 で開発することが必要
ゲームの会社って意外とレビュー会やってない
やってたとして偉い人が偉そうに座ってて話しづらいので 意見が出せる雰囲気のレビュー会 を用意
→ 付箋に意見書いて匿名で出すとか
雰囲気のいい開発現場を目指して「モスバーガーのカンバン」
→1日1個小ネタを書く
いくら安全にしても転ぶことはあるから、 転んでも（そこまで）痛くない 場所
大怪我しないために作る練習の場を自分で積極的に開いている
- 勉強会
- ワークショップ
- ディスカッション
学生がチーム開発のメンタリングを改善したひと夏の話
筑波大学大学院 M2 4人
もりや さん
こでら さん
むとう さん
おばた さん
スライド公開されてない模様
メモ
enPiT
筑波大学が行っている全国の大学から参加する2週間の開発合宿
学生メンターと技術メンターがいる
始める前のキックオフで昨年のProblem
- メンターへ質問がしづらい
- 技術メンターの関わり方が明確ではなかった
enPiT Go
昨年の問題を解決するために開発した
メンター呼び出しシステム
- ちょっと来てよーぐらいで呼び出せる気軽なもの
- ホントにポケモンの戦闘画面みたいで面白いｗｗ
- 全員が見れるプロジェクタに写すことで他のチームが相談している内容見れたりして呼びやすい
- 困っていることが明確になってメンターが適切にサポートに入れた
マジで他のハッカソンとかでも使えるものだと思った
というより使って欲しい
エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史 -
小賀さん Masanori KOGA (@makoga) | Twitter
スライド公開されてない模様
スライドはこちら
メモ
チームを超えた技術力評価制度
実績評価は同じ部署の人が行い、能力評価は他部署の人が行う
被評価者は1時間半のプレゼン + Q&Aを行い、評価してもらう
抱えていた課題がどうなったか
- 短期的なスピードを重視しすぎている
様々なエンジニア、グレードの高いエンジニアからのフィードバック
中期的な視点、技術的な視点での評価 - エンジニア評価の納得感
リスペクトできるエンジニアからの評価 - 採用・育成・評価の価値観の統一 軸を作っていたとしても捉え方は色々あるので、Q&Aを通して価値観共有 早い段階で評価する立場に
5年間のカイゼンの歴史
- 評価軸
テストやセキュリティ周りを評価軸に入れた
テストがないコードはなくなった
セキュリティの脆弱性があるコードも減った
↓
全体的に技術力が上がってきたので分かりやすいコードがなくなり、評価軸を変更
実現力、改善力を追加
↓
一般的な用語を使ったことで、定義を狭く捉える人がいたので自分達の言葉で文章に変更
社内でよく使われている言葉に変更していった - 全体ふりかえり
評価フローに追加
当初はグレードが高いエンジニアを集めてやっていたが、今は全員でオープンなディスカッション - 評価結果の公開
評価結果のコメントを全社に公開した
点数制をやめて、総評とアドバイスをしっかり書くようにした
制度を改善していくコツ
- ステークホルダーとゴールイメージ、期間を合わせる
- CTOが主体でやっているということを見せて、能力評価は人事でやることではなく自分達でやることだと示す
- 最初は評価軸を指摘しやすいもの等小さい挑戦から始めてカイゼンしていったもので自分達用のものだからコピペは危険！！
Q&A
Q：若いエンジニアとかから人を評価したくないとか意見はありませんでしたか？？
A：CTOが全て間に入って、フィードバックも評価も全てCTOがやるから責任はCTOにあって評価者はそのサポートしてるだけというところから始めた
アジャイル・メトリクス実践ガイド
伊藤さん The HIRO (Hiro Ito) (@hageyahhoo) | Twitter
スライドはこちら
メモ
メトリクスとアクションの共通化・標準化が進み、プラクティスが一般化している
メトリクスの基礎
ソースコードの品質を「数値化して定量的に評価すること」、評価手法や基準などの体系のこと
- 取得のポイント
厳密性よりも有用性、メトリクスは事実に基づく必要はあるが厳密である必要はない - 活用のポイント
何か問題について考えることのプラスになる情報を得る
数値の変化に意味を見出す
データを基に、アクションを考える
メトリクスは仮説検証に使用するため、従来にないものを創造する。 世の中に基本的なメトリクスはあるが、自分達に適したものがない場合は創っていこう 経営層には時間を絡めたメトリクスをネタにすると良い
プロダクト開発で必要なメトリクス
- POにとって必要なもの
プロセスメトリクス
プロダクトメトリクス SM・開発チームにとって必要なもの
プロセスメトリクスプロセスメトリクス
開発作業などのプロセスから取得するメトリクス- プロダクトメトリクス
プロダクトそのものから取得するメトリクス
プロダクトが提供できる「体験」
事例
ステークホルダーに対して自動化する前の時間と自動化後の時間を具体的に報告
→ 自動化へのハードルが下がり、さらに進めてくれと言われた
チーム内外全員に対してプラスになるアクションを起こせた
欲するものが見つけやすくなる
→距離が近くなり、協働につながる
メトリクスで「仲間」になろう
メトリクスの実践的活用法
コードカバレッジを使用したYahoo内の事例
問題
- コードカバレッジをアクションの指標にしていたが、カバレッジを上げることが目的になってしまいテストの目的が消えた
- 基本メトリクスしか見ておらず、他の基本メトリクスも欠如していた
- そして、その基本メトリクスを人事評価に使ってしまっていた
アクション
- 導出メトリクスを取得
- 単体テストの目的とメリットを再共有
- 人事評価に使用しないように調整
メトリクスを測定しているチームは測定していないより自己評価が高い
→チームが停滞している場合はメトリクスを測定してみるのも良い
メトリクスの原則
- 計測するものはゴールに直結すべき
- 会話を促すものであるべき
- 行動につながるものであるべき
- 計測するものは少なくすべき
- チーム・プロダクトを成長させるために使用すべき
感想
スゲー楽しかった（小並感）
今のプロジェクトもスクラムやってるけど、正直停滞感というか何かモヤモヤを抱えているので刺激になった
1度別のプロジェクトのスクラム見学させてもらった時も感じたけど外を知るって大事！！
でも、丸コピってダメだとは思うので後は自分でどう自分のプロジェクトに当てはめて色々やってみるかなんだろうなーと改めて感じた日だった
他にも色々あるけどたださえ長い記事がさらに長くなりそうだし、眠いし寝る（2日目もあるし）
JJUGナイトセミナー Javaフレームワーク特集 に行ってきた
6/27に開催されたJJUGナイトセミナーに行ってきたのでその参加レポートというか自分用メモです。
かなり長くなった。。。
まとめる能力(´・ω・`)
【東京】JJUGナイトセミナー Javaフレームワーク特集 - WildFly Swarm / Play Framework / Spring Boot
会場 日本オラクル株式会社 本社 13階
https://jjug.doorkeeper.jp/events/46954
ハッシュタグ：#jjug
Togetter：http://togetter.com/li/992744
WildFly Swarm - Rightsize Your Java EE Apps
田邊 義真さん (@emaggame)
以下メモ
WildFly / WildFly Swarm??
WildFly
Java EE7 対応APサーバ
Java9で入るJigsaw的なModule class loader
WildFly Swarm
各種インテグレーション：NetFlixとか
SpringBootっぽいよね？
Wildfly-bootというrepositoryがあるので元々はこういう名前だったのではないか
All In One のためスリム化は自身で行う必要がある
削ることはできるけど依存してたりするので大変
分割と再構築Fractionという単位で構成されていて必要な物だけ使えるぜ
基本的な使い方
WildFlyを表すcontainerというものをnewする
スライドはmvnだけですがgradleもあるよ
普通のWildFly： 1.ダウンロード/インストール 2.設定 3.起動&デプロイ
通常のWildFlyと比較すると依存性で解決できて、
設定・起動・デプロイはmain()で記述できて楽
Fractions
機能や設定の単位
とりあえず有効にすると、いい感じに設定してくれる
色々あるけど今回は一部紹介
※ここは実際にコード見ながらの説明だったのでスライドを見たほうが良い（15ページから）
core
JavaEEやWildFlyのsubsystem相当
jpaを指定すればdatasourceも付いてくる
Arquillian(テスト)
Mockを使わず本物のEJPやCDIコンテナを利用できる
WildFly を事前にインストールする必要があるけどSwarmは不要
Netflix OSS
現状はRibbonとHystrixのみ
使う下準備を支援
必要なライブラリの用意とか
Spring Bootみたいに annotation 1発で色々やってくれるわけではない
→issueが上がっている
興味ある人は公式tutorialへ
Topology
サービスディスカバリ
jgroups consul openshiftの3種類の実装が利用できる
3種類の実装があるが、意識せずにサービス登録可能
keycloak
認証/認可に対応した SSOサーバ
認証クライアント設定用APIを提供
マイクロサービスで1個1個認証書いているとツラいので認証サーバ用意するときに使える
Swagger
APIからドキュメントやモックを生成
JAX-RSで利用する場合下準備がかなり必要だがそれをやってくれる
annotationを追加することで動作を登録できる
Swagger UIを使ってドキュメント化が可能
Spring/Spring Boot
Spring + WildFlyはよく見かける組み合わせ
「対立する必要はないと思っている」
ユーザガイド未記載のためサンプル参照
便利な機能
project-stages.yml
ステージごとに設定が可能
起動時にステージを指定する
コミュニティ
最後に
一通り WildFly Swarm を触ってみるガイドを作ってみたとのこと
WildFly Swarm Tour
まだGAではないものの大分安定してきた
開発から1年で今後活かすも殺すもコミュニティ次第
Q&A（曖昧）
Q：Arquillianはサーバ立ててやりますが、一部だけモック化して行うことは可能ですか？
A：一気通貫でやるのがArquillianの方針であると思っていて一部モック化というものはやったことがない
The High Velocity Web Framework For Java and Scala
株式会社 DTS 梅澤 雄一郎さん (@garbagetown)
PlayFrameworkドキュメント翻訳仲間募集してますとのこと
スライドは後日公開？
公開されてた
免責事項：PlayはWebのフレームワークであり、Javaのフレームワークではない。
以下メモ
Playの歴史
Frameworkは登場の背景とかを知ってないと間違ったところに適応されることがある
1系は 1.2 で終わったと思ったら、最近エストニアの方がメンテしている
Play1の歴史
Java6とかSAStrutsとかの時代、傍でRailsが絶好調
Java全体で停滞感
SunもOracleに買収された
WebはステートレスだからServletやめたった的な感じ
http://ikeike443.hatenablog.com/entry/20120107/p1
Javaではないなにか
Javaの非合理な慣習や機能不足への調整
長ったらしいパッケージ名とか言ってたけどメモ追いつかなかった
そしてPlay2へ
これからリアルタイムWebだから非同期に
Play2の歴史
2012~
フレームワークの世代交代
当時はJamesが牽引していたがLagomに専念するらしい
Scalaで全面的に書き直し
2.0 当初は不十分で品質も不安定でメーリングリストが荒れた
2.3 から品質が安定
Akka統合
Akka：並行分散処理フレームワーク
特徴
Webフレームワーク
- Servlet API非依存
warも出来ないこともないけど茨の道
組み込みNettyで動作（ここがAkka HTTPに変わるかも） - ステートレスアーキテクチャ
サーバ側セッションなし
Railsと同じでクライアント側Cookieセッション、Flash
ホットリロード
- サーバを再起動せずに開発
組み込みECJでcompile
クラスローダ差し替え - Java/Scalaソース以外も静的検査
アセット、トランスファイルしてくれる
基本的にScalaにcompileされる
スキーマ管理
Evolutions
フルスタック
Web開発に必要な機能をデフォルト提供
- ORM
- バッチジョブ
- Test
- WebSocket
- MVC
モジュール
便利な機能をモジュールで提供
Java/Scala API
非同期処理
Akka Actorに委譲する
「lagomとの統合も進むとPlayの役割がなくなっていくのでは」
lagom
マイクロサービスフレームワーク
サーキットブレイカー搭載
Java APIが搭載
使い方
Play2.4/Javaでの紹介
黒い画面苦手な人向けにActivatorUIもあるよ
PlayはRailsみたいにmodelの方にfinderを作ることが多い
View は Scala で書くのでScalaは避けられない
テンプレート名.renderでビューをレンダリングできる
conf/routesでルーティング情報を一元管理
router.Routes.scalaにcompileされる
利点/欠点
Play1
- 大きな仕様変更はない見込み
- 軽快な開発（ホットリロード）
- Lombokとの相性が悪いらしい
- ギヨームがコミッターを外れたのでサポート体制が不安
Play2
- Scala Webフレームワークのデファクトスタンダード
- Play2を追いかければリアクティブを追っていくことになる
- 下位非互換性
- compile速度 「APIサーバとして利用すればいいんじゃない？」とのこと
Q&A
Q：Play2とServlet使ってるSpringとかとの性能の差はありますか？ A：単純なHTTPサーバならそんなに差はない モバイルからとかDBにバンバン書き込む場合はAkkaに丸投げするのがいいでしょう
From Zero to Hero with REST and OAuth2
Pivotalジャパン株式会社 槙 俊明さん (@making)
当初は「Spring Bootで作る簡単OAuth2 SSOシステム」でしたがタイトル変更
時間延長で1時間の枠に
9割ライブコーディングで、正直言ってかなり速かったので全然メモが追いつかなかった(´・ω・`)
メモ追いつかないどころか内容もほぼ追いつけなかった orz
速すぎてついていけないのにとりあえずSpring BootでSSOしてみようと思わせるプレゼンでした
とりあえずコチラに従えば同じものが作れるのでやりましょうってことで
OAuth2
トークンを払い出すためのフローがいくつかある
- Resource Owner Password Credentials
UserID と Passwordを使ってトークンを払い出す
認証サーバにアクセスしてトークンを払い出してもらってそれを保持 - AuthorizationCode
Web UI -> authorize認証サーバ -> redirect -> loginpage -> Web UIがcode取得 -> redirect
以下なんかとってたメモ
簡単なメッセージを登録するものを作成
CrudRepositoryをextendすれば自動でCRUDできる
HAL
HAL Browser(Swaggerみたいなもの)
@RepositoryEventHandler(Entity.class)
eventでのトランザクションも
@Transactionalつけとけば一緒なトランザクション
つけなければ別トランザクション
@EnableResourceServerつけて
@RequestMapping(path = "/userinfo", method = RequestMethod.GET)
Object userinfo(Authentication authentication) {
return authentication;
}
作ればTokenを払い出した人の情報を返すAPIを作成できる
resourceserverに「security.oauth2.resource.user-info-uri」を追加すればtokenを持ってアクセスしてきた人の情報を取得できるようになる
HATEOASを使うと _link とかの形式のJSONを、Javaのオブジェクトにデシリアライズできる
Twitter連携とかで出てくる許可しますか画面出てくるけど設定で出さないようにも出来るよ
「@EnableOAuth2Ssoをつければいろんなことやってくれます」
JWT
GitHub 連携したら遅く感じたのはREST APIが毎回ユーザ情報をAuthorizatioon Serverに問い合わせているせい
JWTを使うと解決する
Spring の自動設定から外れる
鍵の情報を設定する必要あり、propertiesだとつらいので yaml
Maki Home UAA
「槙家のAuthorization Server を使えるようにしてある。OAuth2に準拠していて、拡張しやすい」
「家庭内システムあるでしょ？アカウント毎回作ると嫁が怒るからSSOするしかない」
感想
ちゃんと全部真面目に聞いてたけど正直、槙さんのライブコーディングが速すぎてスゴすぎて全てをそこに持ってかれた感
ライブコーディング見てたけどもう何が起きてるのか全然ついていけなかったのでとりあえず写経して動かしてみるところからやらないとダメだなという結論
Spring Bootは触ったことあるけど、WildFly SwarmとPlayは触ったことないのでとりあえずなんか動かしてみよう
梅澤さんが仰っていた
「Frameworkは登場の背景とかを知ってないと間違ったところに適応されることがある」
という言葉がグサッときた
たけこうブログ始めたらしい（ちゃんと書いた）
初めまして たけこう というものです。
3時間前くらいに書いた最初の記事がふざけすぎてたのでちゃんとしたやつ書いときます。
talfi.hatenablog.com
ちゃんと自己紹介的なもの書いてみる
たけこうです。2014年からみなとみらいにあるSIerで働き出して社会人3年目になってしまった人です。
気付いたら2年2ヶ月経過してた。。。怖い
2016年6月現在はScrumでJava使ってWebサービス作るプロジェクトやってます。
一応認定スクラムマスター持ってます。
エンジニアですが意識低い系エンジニアやってます。
休日はプログラミングとかやらず、趣味にのめり込んでることが多いです
最近PS4買ってしまったので休日はゲームに消える
PS4をゲットした pic.twitter.com/tRcPZirWJ6
— たけこう (@talfi121) 2016年6月4日
マンガ・ラノベ・ゲーム・アニメとかのサブカルチャー的なもの好きです。
好きですが多くは知らないにわかです。ごめんなさい。。。。
物語シリーズ・コードギアス・ばらかもんとか好きです
ロング時代のガハラさんが好きです
ブログやる理由・ブログに書いてくもの
会社の年上後輩（@toyosge）にやった方がいいよ（やれよ）的な発言をされたのでとりあえず作った感じ
ブログは気が向いたら更新していく感じで、技術ネタにこだわらず書いていくつもりです。
多分。きっと。
過去 アメブロ 作って全然書かなかったから保証はしない
なんだかんだ言って技術的な記事多くなるんだろうなーとか思ってたりします。（日常の事とかTwitterで十分でしょ）
