20180629JSUG勉強会-ハンズオンに参加してきました。
20180629JSUG勉強会-ハンズオンに参加してきました。
メモについて、公開したいと思います。
講義パート（30分）
- スライド
www.slideshare.net
- Spring5に触ったことある人→１０名ぐらい
- Spring4以前に触ったことある人→２０名ぐらい
- Spring触ったことない→１名
- スピーカーはカサレアル多田さん
- 2018年10月31日（水）にSpringFest開催決定！！場所は去年と同じ両国の会場
- Sprinとはいろんなフレームワークの集合体
- Spring5はJDK8ベース。JDK7では動かない。
- JDK9／10対応している。JDK11にも対応予定あり。
- DIとは、必要なインスタンスを外から代入すること。newするのではなく、外から与える。
- DIコンテナとは、インスタンス（Bean)の格納庫。DIされるインスタンスをBeanという。
- Bean内に対しては全てBeanをDI済み。
- @Configurationとメソッドへの@Beanは併用可能
- Spring4.3?から引数一つのコンストラクタに対しては@Autowiredは省略可能
- 今おすすめなのは、今ベータ版であるが、Spring Data JDBC（Spring JDBCのラッパー）
- ServletInitiraizerを使ってSpringMVCはDispatcherServlet(すべてのリクエストを受ける唯一のServletクラス)を登録している
- ViewResolver:ビューのパスの一部をビューの完全なパスに解決する
- DB等にパスワードを保存するときは、PasswordEncoderを使ってハッシュ化して入れるのが一般的
- thymelaf-extras-springsecurityを使うと、認証や権限により表示・非表示を切り替えることが出来る
- SpringBootの特徴は3つ
- Auto Configurationクラス
- Spring BootによってJava Configが用意されているだけ
- Starterライブラリ
- 大量の依存ライブラリが1つにまとめられている
- Starterを指定することで大量のライブラリが追加される
- 組み込みアプリケーションサーバ
- サーバーの設定の必要無し
- クラウド向き
- Auto Configurationクラス
- SpringBoot2の大きな変更点としては、SecurityとAccurator。
ハンズオン
- 資料
- InteriJを使っている人は会場の中で10名ぐらい。他はSTS or Eclipse
- 自身の環境はSTSのバージョンが古く、Junit5が動かなかった。。その他環境起因の不調が何度かあり、色々助けていただきつつOptionA（Acctuator)まで動かすことができた！！
- チューターの方、困らせてしまいすみませんでした。
多田さん、チューターの方、ありがとうございました！！
20180611 Rochelle Kopp: 自分の組織でチェンジメーカー（変革を起こす人）になる方法に参加してきました。
20180611 Rochelle Kopp: 自分の組織でチェンジメーカー（変革を起こす人）になる方法
所感
- （当たり前ですが）エンジニアだけではなく様々な背景を持った人が多く、グループワークやQAなどから色々考えさせられた
- 自分もRochelleさんのtwitterで発見して参加した口なので、Rochelleさんファンが全体的に多かった？
CodeCysaris :英語とプログラミングFull Timeで教えるスクール。３ヶ月でFull Stackエンジニアリングリーダを育てる。
- Rochelleさんがアドバイザー
自分の組織でチェンジメーカー（変革を起こす人）
about Rochelle Kopp
２つのモデル
- 誰が変革をリードするのか？上級管理職だけに変革のリードが任される時代は終わった
- リューインのモデル；解凍→変革→再凍結
- 現状は氷のように凍結してしまっている。まずは解凍することが大事。そこで水の形にして、新しい形で凍らせる。
- コッターのモデル；変革を8つのステップに分ける
- 何かを変革を起こすには、まずみんなが何故変革する必要があるのかを理解する必要がある。（今のままでいけない理由、変革したほうが良い理由、何もしなければ不利な状況になる理由）
- 日本の企業は失敗することを恐れる。失敗することで将来がなくなる、とか。
- ビジョンと戦略を生み出す際は、恐怖感に対する対策を打ち出すことが重要。
- 嫌々ながら上から言われたからやるのではなく、自分自身がやりたくなって導くことが大事。
- スタートして分析してもう一度考えることも必要。
- うまくいったら皆に伝える。Nothing succeeds like success.
- 解釈としては、成功のようには何事も続かない。→ →成功ほど続いて起こるものはない→一事成れば万事成る。 ということわざ。
- 社長がキレイなことを言うだけではうまくいかない。危機意識を高めて、変革改善のための連隊チーム（Cross function team)の組成が大事。
- 場合によってはインセンティブを検討する必要があることも
- 下の方から変革させようとする場合、自分たちで短期的成果を実現することにステップオーバーすることのやり方も。ダメージが少なくてすむ。
変革を体現する（Modeling the Change)
- 日々の責任業務として、変革に関わる目標を掲げる
- 周りに自身の行っていることと、行動にGapがある場合は指摘もらうように関係を築く
- 変革のためにはコミュケーションを上手にする必要がある
- 各個人にとって、この変革はどんな影響をもたらすのか？自分にとっての利点は何か？残業時間が減る、など個人レベルまで落とし込むことが大事。
- 変革の時に過去、今までを否定するのはNG.基礎に基づいてよりよくしていく。改善のニュアンス。
- 企業文化の重要なところはなんなのかを分析して、そこを続けるようにする必要がある。それを明確に定義することによって変革しても軸が守られる。
- テストの環境、トレーニングの場、時間を提供することが大事。自信を持てるようにする。
- 変革のための６つの行動（How）
- ・変革に関する行動：Gapがあれば、分析、修正。
- ・コミュニケーション：ここ失敗すると、進まない（できるだけ多くの手段で）
- ・他の代替手段：
- ・関係者全員への伝達
- ・結果と実現性の通知：
- ・考えを押し付けない：なぜ嬉しいか、説得する
- Next Action
- 従業員の自発を促す
- シェアすると実行確率が上がる。
- 一方的にこうしよう！じゃなくて、皆の提案を出してもらうほうがうまくいくケースも。（やらされ感なくなる）
- モチベーションが低い人にはどうするか？
- もうすぐ定年だから、、このままで良い、、とか。
- その人の価値観を探る必要ある。その人がExciting、やりがいがあるものを引き金にする必要がある。
- または、その人がモチベーションがなくなった原因が会社を作ってしまったことに問題がある。
- 売り上げが２倍、、とかはあまり魅力的なビジョンではない。
- 売ることによって人、社会が助かることが結果的に売り上げに繋がっているというのが魅力的。
- もうすぐ定年だから、、このままで良い、、とか。
- 日本企業の社員は、なぜこんなにもモチベーションが低いのか？という本もあり。
JSUG勉強会 2018年その2 SpringとAPI時代の動く仕様への取り組みに参加してきました。
3月7日（水）に開催されたJSUGの勉強会に参加してきました。
いつものPivotalLabの会場いっぱいになるぐらいに参加人数も多く、盛況な状況でした。
スピーカの方がSpringの説明として「SpringはJavaのエンタープライズ開発の屋台骨と化している（Springエコシステム）」と改めて説明されていて、ますまず学習する必要あると再認識しました。
以下、それぞれのセクションごとのメモです。
後半はちょっと体力的に電池切れ気味でした。。（自身知っていた内容でもあり、、）
動く仕様テスト編
- システム設計の謎を解くという本の筆者曰く、「設計とは”考えること”であり、アウトプットはその一側面である」
- テスト仕様書だけでは、テストできない現場に遭遇
- 事前フラグを立てる仕様をだれも知らなかった
- 事前の状態、条件を表現することを忘れがち
- 例1：エアコンの設定温度を20度にすると冷たい風が出る。
- 例2：一覧画面からボタン押すと詳細画面に。0件の状態ならどうなるか？
- given-when-thenでテスト仕様を表現する。
- テンプレート：[given]の状態で[when]すると[then]となる
- SpockというJunitのようなものがある。（groovyのテストフレームワーク）
- given-when-thenでテストが書ける素晴らしいもの
- 自動テストは動く仕様である
- Junitではどうするか？まずはテストメソッド名をgiven-when-thenの形で書くことを始めるのが良い
- 例：カートにアイテムがある状態でカートを開くと購入可能である()というテストメソッド名にする。実装はgiven-when-thenを順番に記載していく。
- Spring FreamworはDIコンテナから生まれている。DIコンテナによりテスト時のMock,Stub化が楽になった。
- 状態中心のテストと、相互作用中心のテストという２種類がある
- テスト対象のクラスのメソッドをMock化してよいの？という議論があった。スピーカーとしては、テストしたい観点がテストできていれば絶対NGという訳ではないと考える（三角測量的な観点）
- 会話、整理する場合は、仕様の粒度があっているかを最初に確認することが大事
- 仕様はビジネスで使う用語で表す
- コミュニケーションは永遠の課題。アプローチや取りうる策は増えてきているので、今後もいろいろ検討していくべし！
API編
- 従来の開発あるある
- 試しに画面レイアウト作成ーイメージとちょっと違う。。
- 設計書サンプルーユーザー属性が1つ抜けてる。。
- 実装の都合上、設計を返させてくださいー検証環境で触ってみたい。。
- バグ、要望の嵐。。
- 序盤で漏れなく検討する必要がある
- 実例プロジェクト
- 仮説検証型開発を適応
- クライアント：早い段階で検証する：Swaggerを使う
- ベンダ側での検証サイクルを回し続ける：SpringFox
- Springのソースコードから仕様書を自動生成できる（CIで回すと便利）
- ドキュメントの乖離をなくす：Spring Rest Docs
- テストコードから設計書を作成する。成功したテストケースしか出力されない
- テスト後にasciidocフォルダにドキュメントが吐かれる
WebAPIのところはエンプラでAWSとかも使いつつどのように一連の開発をしていくのかは、今後整理していきたいところですね。（流れも速いエリアですが、、）
運営の皆さん、スピーカーのお二方、ありがとうございました！！
GlassFish Users Group Japan 勉強会 2017 Winterに参加してきました！！
GlassFish Users Group Japan 勉強会 2017 Winter
MicroProfileの概要と最新状況 (@n-agetsu)
www.slideshare.netMicroProfileのキャッチアップになりました。12月22日リリース予定という1.3を早く試してみたい。Spring Cloud+ Netflex系OSSに追いつこうとしているところが興味深い。
- JavaEEと同様、仕様と実装（Payara,Wildfly）が別れている
- FujituはAPサーバ実装をRIとして一部機能を提供している
- ConfigAPIはできることとしてはDeltaSpike(CDI拡張モジュール)とほぼ同じ。Springの@Valueの方が高機能
- Fault Tolerace : NetflixのHystrixやSpring Retryを目指す
- リトライ（@Retry(maxRetries=10)
- サーキットブレーカー（@CircuitBreaker、@Fallback)
- 故障したサービスを呼びださない。故障認定したら対向先を呼び出さないので、応答が早い。復旧機能もあり。ハーフオープン
- Metrix1.0 JMX相当の監視をREST-API経由で提供。フォーマットも規定。json, Prometeus formatも必須サポートするように仕様に明記している
- MicroProfile1.3
- OpenTracing1.0 : 主にZipkinとの連携（データの送信、収集）
- JAX-RSのサーバ、クライアントの自動トレース送信（修正なしで自動的にトレース）
- OpenAPI1.0:swagger相当の機能。API実装にアノテーションを定義する。yaml or jsonの生成まで。UIやCodeGenは含まない。
Java EEでもOAuth 2.0！~そしてPayara Micro on Cloud Foundryで遊ぶ~（@suke_masa）
以前JJUGで聴講した内容の再演＋α（デモがCloud Foundaryベースになっている）。
理解が深まった。
- Oauth2.0:認可の流れを規定したプロトコル（RFC6749).not 認証
- アクセストークン：クライアントがリソースサーバにアクセスする際の通行手形のようなもの。認可サーバから発行される
- OAuth2.0の認証サーバが直接アクセストークンをブラウザに返さずに認可コードのみ渡すのかは、ブラウザ側にアクセストークンを流出させずに、クライアントAP内(TweetDeckなど)に留める為
2018年のGlassFishとPayaraの動き (@khasunuma)
資料公開は見送り。。とのこと。
JJUG CCC 2017 Fallに参加してきました
JJUG CCC 2017 Fallに参加してきました。
家族イベントがあったので、午後からの参加です。
１コマ目
安定のカサレアル多田さんのセッション。教えるプロということもあり
説明がわかりやすい！Springは使う一方で内部構造全く理解していなかったので
内部ソースを追うきっかけをいただいたセッションでした！
以下がセッション内メモ。
- SpringMVCはDispatchServletで全リクエストを受付、この中にコンテナを持っている
- ViewResolverインターフェースで、テンプレートエンジンの切り替えなどw実装できる。
- SpringMVCは拡張、差し替えしやすいように徹底的にインターフェース化されている。バリデータ、コンバータ、URLとコントーラメソッドの紐付け
- 過去はたくさんの@Beanで定義が必要であったが、@EnableMvcだけでよくなった。 中身は@Import
- ＠Controllerの中身は@Component.
- SpringBootは何を自動化するのか？ コンテナはフレームワークを動かすBeanと、業務で使いたいBeanに別れる 業務側は、コントローラとビジネスロジックとリポジトリ、ぐらい。
- >SpringBootが行うことはフレームワークを動かすBeanを定義済み ⇨大量のJavaConfigの塊
- セットアップ最小限ですぐ開発できる。アプリを構成するBeanにはノータッチ
- application.propertiesで記述した設定はAutoConfigurationクラスに渡されて使われる
- spring.factoriesを読み込み、記載されている次に読み込むAutoConfigurationの読み込みを行う
- spring-boot-autoconfigure.jarには、ほぼ全てのBeanが定義されている。 Springイニシャライザーで複数コンポーネントを選定するが、上記設定ファイルにはほぼ全て最初から書かれている ⇨選定が行われる。条件は@ConditionalOnXX ⇨クラスパス上にthymeleafのライブラリがあれば、Beanを有効化するなどの 実装がかかれている
- EnableXXをつけない、自前でBean定義しないのが安全 安全なカスタマイズ方法:補助的なBeanを定義して、コンテナから拾ってもらう Bootで準備されている、XxxCoustmizerを使う
2コマ目
qiita.com事前に調べてから行けばよかったのだが、過去に別の勉強会で話して、
QiitaにUp済みの内容でした。既視感がすごかったです。
ただし、デモや説明として聞けたことが大きかったです。
- SecurityはServlet のFilter機能を利用してセキュリティ機能を提供するフレームワーク
- セッションIDの盗用はクエリパラメータにセットする、など。
- SpringSecurityはURLリライティングを検知して、消す処理がデフォルトで備わっている
- ログインの前後でセッションIDを変化させないとダメ
- SpringSecrityはFormログインしたときにはデフォルトでセッションIDをかえてくれる
- CSRFリクエストが正規のページからきたことを確実に判断することが大事。
トークン発行など。 - SpringSecurityではデフォルト有効
- クリックジャッキング、みえないiframeをボタンの上に乗っけて正規のページの処理を動かされている
３コマ目
資料はアップしないとのこと。Oracle正式見解として、Web上にページ公開を
社内で計画しているから、、とのことです。
- JavaーCadence：リリースモデルを変える話
- JDK9は過去最大の機能追加数：９１？
- JavaSEのリリースまでには２つの関門が。
OpenJDKー＞JCPの投票 - 新しいリリースモデル11/17現在
６ヶ月で定期リリース、削除提案、削除実行のプロセスも含まれる - OpenJDKもバイナリでもリリースする。v9.0.1が最新
- 1年後のリリースまでにOpenJDKを機能強化させ、OracleJDKと同機能まで持っている.フライトコントローラ、ミッションコントローラ
- Z garbage Collector:オラクルのインターナルプロジェクト、マルチテラバイトGC、10msec以下
Application Class Data Sharing,
Ahead of Time Comlilation：出せるのかが不安になってきている。引っ込める可能性もある - コミュ二ティとの連携は継続、OpenJDK,JCP
- OracleJDKはLTS版のみのリリースとなる。11LTSの次は17LTSとなる
- 半年毎のリリースはOpenJDKのみ。
- リリース情報の提供はOpenJDKにのっているものが最新。Featuresの欄が新機能情報。
http://openjdk.java.net/projects/jdk/10/ - リリースドキュメントも重要。Deprecatedの運用ルールはそのまま
⇨最短1年（Deprecated：削除タグがついて２バージョン後）で機能が削除される可能性あり。 - CORBA関連の機能がなくなることがJavaOne内で言及があった
- Oracle公式アップデートの終了
- JDK8:2018年9月,9,10は半年。
- 8の移行先は11移行推奨。9,10は機能評価用として利用すべきもの。
- Java8のDeployment Techonologyは通常のJava8より短い。Applet,JWTなど。
- OpenJDKでもLTSという話がでてきた。（DevoxxでMarkRainfoldが言及）
- IEはJavaSE9の64bit版を認識しない。
- *JavaSE9以降は自動更新は行われない。
- *JavaSE9の32bit版のバイナリ提供の予定は現状なし。
４コマ目
pring BootとKafkaでCQRSなアプリを動かしてみる
#ccc_e6
楽天椎葉さん
ツイッター上でやり取りさせていただきました！レスポンスあって嬉しい！
物腰柔らかくて良い人でしたー。
ありがとうございましたー。CQRSはまだ使ってませんが、Spring Boot自体は使ってますよー。
— しーば (@bufferings) 2017年11月19日
- CQRSはGreg Youngが名つけたもの。
- コマンドとクエリを別のオブジェクトに分ける。
（プレゼンの図はCacooで書くとかきやすい） - 複雑なものをキープしたい、複雑なものをどうやって改善するか。。
- DDD：ソフトウェアの複雑さの核心にせまる
- DDDの印象：依存関係を切り離し、凝縮させて複雑さを回避していく
- DBからの解放はステキ。だけどUIからの解放は難しかった。集約とか、集約からの導出した値で検索やソートをしたり。。
-> JOINを使い、妥協した - ドメインモデルは更新側が重要。クエリ側はDAOにしてしまう、といったアイデアもでてくる
- ステートソーシング：現状の状態を連携、管理する。ビール残り３本、残り１本、など
- イベントソーシング：起こった出来事を管理、連携する。ビール３本買って来た。１本飲んだ。など：過去の履歴が追いやすい
- CQRSとするなら、
更新側ではイベントソースに投入するのみ。そこからDBに非同期で反映。 - CQRSはEvent SourcingへのStepping-Stone(踏み台)
- CQRS/Event sourcingを全体に適応しない。コストが高く、難しい。必要なところに集中してやるのが良い
- Kafka 分散ストリーミングプラットフォーム
- MQの場合はキューにはいったものが読みこまれると消えてしまうが
Kafkaは読み取っても消えないし、過去の分も読み込める
最後のコマ
Serverspec NTTDataのサーバスペック活用のお話
- アプリの自動化は進んでいたが、インフラ自動化はなかなか浸透してこなかった。
- 商用ミドルウェアの単体テスト自動化 #jjug_ccc #ccc_a8
- これまでは
- パラメータシート＞構築手順書・テスト項目書＞構築対象
- を全て手動で転記や対応。
- 案件での実績としては110ノードの単体テストを作業ミスなしで３週間の遅れをとりもどす！
- パラメータシートのフォーマットがミドルウェア、チームごとにバラバラ
- WebLogicだけでも2800以上あった。自動化スクリプトが肥大化＆未管理
- ・パラメータシートのフォーマットを統一化
- ・そのシートを元に自動生成の定義（自動）と、テストスクリプト（手動？）を生成
- WLSTが内包されていて、便利なので活用する方針
- テストスクリプトをテンプレート化し、変数群をyamlに転記するよう自動化。
- 状態確認ができるものはそれをやる。できない場合はデプロイ後の設定ファイルを確認する。
- ⇨テストパターンによりテストロジックを共通化する
- フォーマットやツールについては現状公開予定はないが、他社さんとかで公開している事例があるので
参考にした方が良い。 - １Nodeで複数ミドルウェアをいれてるとインストールする中で勝手に変更するケースもあり、
考慮が必要。（順序性とか？） - QAタイムでパラメータシートExcelとか、転記マクロとか公開してくれませんか？とお願いしたが、現状予定なしとのこと。世の中にもいくつかあるようだとのコメントいただいたので、時間あるとき探したいと思いましたー。
懇親会は家族とのご飯予定があったので、帰りました。寒い日でしたが
イベントはアツかったですね！
運営とスピーカーにいつも感謝。
おつかれさまでしたー。
Set.ofの実態とは？
Java9から、Set.of関数などデフォルトメソッドがインターフェースに
実装されたので、簡単にSetのオブジェクトが作成できるようになった。
実体として何のクラスのオブジェクトが作られるのか気になったので
やってみた。
$ ./jshell
| JShellへようこそ -- バージョン9
| 概要については、次を入力してください: /help intro
jshell> Set.of("a","b")
$1 ==> [b, a]
jshell> $1.getClass()
$2 ==> class java.util.ImmutableCollections$Set2
ということで、java.util.ImmutableCollections
が実クラスでした。イミュータブルなものとして使えるというフレコミだったので、そのままでした。
SpringBootハンズオン#2 に参加してきました
2017年7月26日にYahoo!ショッピング主催のSpringBootハンズオンに参加しました。
SpringとPCFがハンズオン形式で学べるとのことなので、
楽しみにして参加してきました。
事前にそこそこ触ってから行き、資料がかなりシンプルに分かり易く作られていたので
集中して、サクッと経験を積むことができたのが有難かったです。
やったことは以下です。
- SpringBootアプリの単体テスト
- SpringBootアプリのDBテスト（Junitで実行できる形）
- SpringBootアプリのEtoEテスト（Junitで実行できる形）
- PCFの起動、デプロイ
- PCFでのスケール（スケールアウト、スケールアップ）
- PCFでのブルーグリーンデプロイメント
動かしてみて初めてわかったのですが、SpringBoot系の推奨テストは
Junitベース。コンソールを見てると都度都度SpringBootを起動しているログが出ていた。
テストケースが多いと、時間がかかりそう。。そうなったらグループ分けなどして複数プロセスとかで並行テストとかを考える必要がありそうと感じた。
Yahoo!ショッピングさん、貴重な機会ありがとうございました！！！
