JavaからC言語のロジックを呼ぶのをお試し
簡単なCで書かれたロジックをJavaから呼び出すことを試した。
環境はMacOS
参考サイト
gccのコマンドをどうするのかが最後なやんだ。試行錯誤で最終うまくいったコマンドは以下。(historyから抜粋）
vi hello.c
vi HelloJNI.java
javac HelloJNI.java
javah HelloJNI
gcc -shared hello.c -I /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/include/ -I /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/include/darwin/ -o libhello.dylib
java HelloJNI
以下のサイトも参考になりそう。
JNI helloworld | Adamish | Blog
つくったソースとコンパイル結果のライブラリは以下リンク先に。
Agile Japan 2018 に参加してきました！
AgileJapan2018に参加してきました。
全体の印象としては、アジャイルやってみよう！という人よりは今やっている、もしくはやり始めたところの人たちが多かった印象。
他の会社ではどうやっているの？とか、自分がアジャイルをやっていてぶつかった課題に関するヒントを得に来ている感じ。
JapanTaxiの川鍋社長のプレゼンがとても引き込まれるもので良かった。
資料が公開されたら、参加できなかった裏番組セッションも含めてじっくり見直したい。
以下は参加中にとっていたメモです。
運営の方、登壇者の方、お疲れ様でした！！
Agile Japan 2018
- 今年で10周年
- 今年の参加者は542名の参加者（登録者数）
- うち今年初参加388名
- Agileはキャズム（深い淵）を超えた。今後のはさらに広がっていく見込み。
- Agileはわかりづらい？ Do Agile? Be Agile?
- 常にWHYを意識することが成功へのカギ
- 変えることが大事になってしまうと、本来の目的を見失ってしまう
- 常にWHYを意識することが成功へのカギ
- event hubのスペースが用意されており、Mob Programmingブースもあり。去年から初めて大盛況。第一人者のWoody Zuill 氏による
株式会社オージス総研 藤井 拓 氏
基調講演その1:Woody Zuill 氏
- 楽天川口さんのつてで登壇。企業向けに英語の公用化の支援。アプリ、塾など。
Woddyさんセッション
- 平鍋さんによる通訳！
- Mob Programming and tho Power of Flow
- 同じことを同じ時間に同じ場所で、同じコンピュータでやる
- 知識がバラバラの人を集めてやる。なぜかうまくいく。
- Driver(チームからInputを受けて、チームの考えをoutputするだけ) / Navigator
- アイデアをシェアする。簡単ではないが、練習すると出来るようになる
- リモートによるVirtualMobでやっている事例も。
- NASA Mission Controlも１種のMob。専門性の高い知識を持つ人が１箇所に集まる
- システムは一つ一つを集めてもできない。それぞれの
- 効率性（正しくやっているか？）、生産性（Outputがでているか？）、効果的かどうか（正しいことをやっているか？間違ったことを早くやるのではなく、遅くてもよいから正しいことをやりたい）
- ５人で生産性があがるか？ 質問が誤り。５人で効果的(effectivity)か？を知るべき。
- 効果的なものを破壊するものは何か？いろいろあり、人によって異なる
- Mob Programmingをやり始めると、これが消える。効果的に働くということにフォーカスした結果。
- Question Queue Time。VSMを整理すると、質問して待っている時間が無駄。
- 普通は、待っている間に他のことをやる。そうすると、在庫を抱える、コンテキストスイッチが入る
- One Peace Flow 日本語でいうと一個流し。１つのタスクにしかかったら終わるまでやりきる
- 心理的なFlow、物理的なFlow
- 前者は没入状態、自分と相手の区別がつかない。Zoneに入っている。時間の感覚もなくなる
- Team Flow.仕掛かり状態なく、待ち状態もない
- ソフトウェア開発は、ideaがソフトウェアでデリバリーされる。それがキューなく、待ちなく、割り込みなく、リラックスした状態でできるか？
- Mob Programming は一人一人を最大限引き出すのではなく、みんなから一番いいところ引き出す。
- モブプログラミングは、仕事のフローに対して最適化されている (一人一人のアウトプットへの最適化はしていない)
- 製品開発でもっとも大きな問題はキューとされている。Mobはソフトウェア開発におけるキューの問題を解決する
- 個人のFlow、チームのFlow、LeanのFlow
- 大事なのは、アートを作ることではなく、自然にアートを作れる素晴らしい状態にいること、環境になっていること
- 参加者のBlog： https://hackmd.io/kbddZClZRzyAhRnMkFgiCA#
JapanTaxiの挑戦
- 川鍋さん。日本交通の３代目。
- 全国タクシーApp
- GPS ＞ スマホ で急にITが必要になってきた
- 全産業IT化の状況。経営者は全員気づいている。
- JapanTaxiは９０名体制でうち５０名は内製。日々状況が変わってついていくため。
- リアルのビジネスがあってそれにITを足す方やさしい(Japan Taxi)。ITから初めてリアルを後付けするのは難しい(Google)。
- コラボレーティブモビリティ。タクシーと道路舗装会社、など
- 社長自身もtech campに１週間参加し、Rubyもやった。
- エンジニア採用はCTOに任せた
- ハードウェア（シンセンで数千円単位）や、SIMが安くなってきたことが大きい。
- 最近VPOE(Vice president enginieer)の役職を作った
エンタープライズ企業におけるアジャイル開発の取組み
- エンタープライズもこの２−３年でアジャイル導入追加
- エンタープライズ特有の悩み（乖離統制、社内ルール、標準化、契約、委託会社との関係、、）
- 金融企業向けサブイベントを開催（2018/4/26)FISCの人、セブン銀行のアジャイル事例の共有
東京電力；WF文化の企業でSoRにアジャイルを導入してみて起きたこと
- 2016年にHD制に移行。2020年の電力完全自由化に向けての組織変更
- 生産性の倍増と、新ビジネスの創造を目的としている
- Open Speed Co-Operation（共創）をテーマに
- デザイン思考と高速PoC
- 3年で1000のアイディア創造、100のPoCを実施。今後確率をあげたい。
- 6/22にインキュベーションセンターを開設。既存の門前仲町のビルの１フロア。tepsys labs。
- 東京電力が持つファリシティのデータを生で触ることができる
- 福島原発の廃炉プロジェクトを遂行中。30-40年がかり
- 原発の放射線管理に関する業務支援システム
- 人、作業、場に関すること
- 1997年リリースのホストシステム（COBOL 100万Step)
- 24/365、個人情報あり
- 関連法務多数（ステークホルダー多数）
- 作業員の安全確保が最優先。法令や業務設計と並行して、早急なシステム対応が必要。
- スピードをあげた結果、あとからAgileと名付けたのが実際
- なぜWF文化の会社でアジャイルが導入できたのか？
- 非常事態と２つの偶然。：「風土・文化」「ヒト」
- 非常事態：標準を崩してでもスピードをあげてもよい
- ヒト：高いスキルと意欲を持ったチームの確保
- ヒト：業務精通し意思決定が行えるPOが確保できた
- 内の変化：システムプロジェクト規模が拡大、ステークホルダーも増大
- プロジェクトの停滞；ステークホルダーが多く、利害関係が増大。POがボトルネックに
- プロダクトバックログを目的別に分割し、チームも分割
- POに業務部門かた代表者を招集
- 各業務部門長でステアリングチームを構成。POはこのチームとだけ話をすることで負担減
- ホスト統合案件
- パフォーマンス、コスト、リスクのバランス
- チームの維持、割り込み要件対応に応えるためアジャイルで進めた
- アジャイルの中で品質保証をどう取り組むかを検討
- 改良ベースであることはアジャイルに不向きだった
- 開発工程の工夫
- 開発体制の工夫
- ４０名ぐらいの体制
- PO部門が３つに別れていたので、それぞれで開発チームを組成
- 大規模、会議エリアはオープンエリア（声が聞こえる）
- プロジェクト運営の工夫
- スプリント計画
- 案件の内容により、開発チーム編成を変える
- テスト体制は他チームを含めて混成編成とする。（品質、体力面）
- スプリント計画
- 開発手法の工夫
- 計画QCDの達成。業務部門の満足度が高かった
- 課題：属人的、契約の整理が必要
三菱UFJ銀行におけるアジャイルの取り組み～ これまで、今、これから ～
- アジャイルの取り組みのスタートは、不確実への対応
- 方向付けフェーズを儲ける、リリース準備期間（移行フェーズ）を設け、標準化 ＞ DaD同様
- リリース準備期間で他システム連携テスト、トレーニング期間
- 2015年からのLCP開発の体制もアジャイル。一定予算内で継続的な開発。優先度に応じてバックログを見直し。
- 50以上の小規模なアプリケーションを提供
- EFXの事例。モデル開発が変化が激しく終わりがないのでアジャイル向き
- デジタラでは、システム駆動ではなく、会社としてやっている
- カルチャー改革としてのAgile：Culture of Failure
- 課題と取り組み
- 業務部門の関与：個別勉強会やワークショップでの理解促進。ユーザータスク管理手続のアジャイル対応
- 業務部門との物理的な距離；専用のコロケーションルーム、可視性を心がけTV会議等の有効活用、開発PO(Proxy)を通じたコミュニケーション
- 意思決定の遅延：POを組織責任者から実務責任者へ。複数の業務部門が関与する場合は、代表部署のPO(リードPO)を明確化
- アジャイルをよりやりやすく、よりメリットを享受するために
保険会社でAgile? アクサ生命のAgileトランスフォーメーション
- ビジネス競争力強化、働き方改革などの目的に組織を今年1月に大体的に改革
- Agile Coachを会社でやっている３名。
- アジャイルオーケストラと呼ぶ。
- why agile？
- 要件定義が大変。横軸でのコラボレーションが無い（サイロ化）。紙＆サイン文化。複数アサインメント。プロジェクト期間の長さ
- 組織構造：それぞれBP部門に対して、トライブ（縦）、横（ギルド）で組織化。
- トライブ：何をするか、ビジネスパートナーとの関係維持
- ギルド：どのように実現するか？
- トランスバーサル：適切なコントロール、ガバナンス
- 自立的なチーム：End to Endで自立的にプロダクトを開発できるチーム
- T-Skillのメンバー：スペシャリスト＋ジェネラリスト
- 新しいロールと新しい働き方でAgilityをあげた
- POはミニCEOのマインドセット。
- Aglityを高めるために内製率をあげている。エンジニアが重要なロール
- Business Proximimity ITとビジネスとのコラボレーションが成功の鍵- ４段階のコラボレーションレベル
- Community of Practice : 知識を共有、プラクティスのアライン、スタンダード、新しいサイロを防ぐ
- Tool from Management 3.0:Management3.0組織を目指す。システムではなく組織をマネージメントする。権限の委譲、コンピテンシーの開発（マトリックス化）
- Agile Coach:チームやリーダーをリード・ガイドする
ギルドワークス：カイゼンジャーニー執筆者。市谷さん
- 仮説検証とアジャイル開発
- ギルドワークス：正しいものを正しく作る。スタートアップや事業会社でに新事業の支援
- 保険会社、水回り製品メーカ、家電など
- 大企業で新規事業をスタートアプする仮設型仮説検証
- Golden Circle：Why -> How -> What
- Start with why
- なぜ、私はここにいるのか？
- 日本におけるアジャイルとは、挑戦と、敗北の歴史
- XPへの憧れと、その遠さ：すごくいいけどプロジェクトではどうしたらいいのか？問題
- 2006年ごろの顧客との強調と不調、灰色の時代
- 2010年アジャイル侍という突破口、超えられない壁
- 二極化する現場
- 基本はリーン製品開発
- リーン製品開発では、セットベースという考え方が基本。
- 正解を誰も持っていない、不確実
- ベンチャーの場合＝セットが多すぎる。基準がゆるく、なんでもありになりがちで後半で思いつきで変更される
- 大企業の場合＝ポイントベース。却下の失敗（選択肢採用の基準が厳しすぎる。不確実なことでもあらかじめの検討を詳細に求められる）
- 求められるのは、採用の失敗を抑えながら、製品開発を行う手段。仮説の確からしさを検証しながら、漸進する開発：仮説検証型アジャイル開発
- 精度と頻度のマネジメント。バランスが重要。
- 日本食品の事例
- 最初の一歩（SoE立ち上げ）を潰してしまったら、組織がアップデートする芽を数年単位で摘むことになる
- 仮説キャンパスによる仮説立案 -> インタビューや観察を通じた状況の把握（エスノグラフィー）-> 行動フローペースで必要な仕組みの設計 -> プロトタイプ検証
- 必要にして最小限の要求詳細化作戦
- 要求仕様の粒度は、結成するチームと関係者の練度でもって決める（詳しければよいわけではない）
- 過去のポストポーテムを活かす
- キックオフの前に、メンバーそれぞれの過去のプロジェクトでの学びを棚卸しする
- インセプションデッキ「やらないことリスト」でやり方、あり方でやりたくないことを共有
- 常にチームビルディング
- 単純接触効果：接触回数が警戒心を解く
- 間違ってもすぐに正解に取り戻せる力（レジリエンス力）を身につけておくのが大事
- 間違っても即、直せる開発
- 間違うなら、早めに間違っておく：１週間スプリント
- 最初から何をもって完成なのかをあわせる
- POが受け入れ条件をかけない問題
- 仮説検証のフェーズで開発から逆に学ぶ。ともにつくるという案も。
- 内製＋傭兵チーム（ギルドワークス）
- 越境：内製チームが。内製チームが自分が何をしたいのか
- ゴールデンワークルは書くX ２
- 最初はこれまでの延長でしかない。その上でむきなおりをすることで本当のゴールデンワークルをかける
- 大企業の新規事業は２回戦う。
- 最初の関門はプロダクトの方向性を見定めること
- 最大の問題は、コンセプトをまとめたあとにくる。
- 大企業ならではの、社内関係者の調整という関門
- チームで乗り越えるしか無い
- 逆境からのアジャイルをエナジャイズする（元気付ける、勇気付ける、後押しする）
- 逆境だからこそ起きた変化が影響が大きい！
Deep agile people
- 受託開発をずっとやっている会社だと、立ち止まってアジャイルを考える時間、余裕がない
- メンバーからアジャイルやりたいと言ってくれるといいが、やらされだとあまり、、。だがみんながアジャイルやっていきたいというケースなんて実際はない
- アジャイル事業部は全てアジャイル。アジャイル好きな人が集まったわけでは無い。新しく来た人は、そこにあるものとして当たり前に受け入れる
- 顧客側からアジャイルをやりたいというニーズは実感として増えている。
- パナソニックにいたときは最後は100人でスクラムしていた。サブグループわけして進めていた
- 30-40名でやっている現場にアジャイルコーチで入っていった時は、大変だった
- アジャイルコーチはそのScrumが自己組織化してきたら、卒業していく。単価は通常SIより高い
- アジャイルを広めるために、アジャイルという言葉を使わないことで広げるテクニックがある（マインド面）
- 請負で普通にやって、現場のやり方としてアジャイルでやっている。短期でリリースしていきますよというだけ。
- １週間ずつ区切って、わかりやすくなっているだけ、とか
- 最近なぜアジャイルをやりたいか？を聞いても出てこないことが多くなっている。（上の人が、、とか、流行ってるからとか）
- 海外の人と仕事する時に相手がアジャイルだから、日本も合わせて始めるというケースも
- アジャイル、前のXPは開発者のモチベーションを高めるためだった
- 最初はなぜプログラマーが散々ドキュメントかかないといけないのか？無駄では？という疑問がスタート。承認が多いとか
- アジャイルのきっかけは、XPの白本、実践編はピンクの川端さんが訳した本もあった。達人プログラマーも。
- 今おすすめするのであれば、アジャイルサムライ
- アジャイルを広めようとしている人が高齢化してきてしまっているのでは？
- AgileJapanは初参加の人が多い。もともとはスーツの人も呼びたいという背景があったから。
- スクラムギャザリングの方が濃い人が多い
- 既存ルールや規制がある場合でAgileをやろうとするとうまくいかないケースがおおい
- PMBOKとかは変わって来ているので外堀は埋まってきている
- 最後は企業内ルールの変更などに壁がある。最初は目的があってルールを決めたはずなのに、今目的が変わってルールを変更するとなると、ちょっと時間がかかる
- アジャイルの品質。QA部門が開発チームの外にいて、そこと一緒にScrumのタイムボックスに入ってもらってやる人は会場で３割ぐらい。
- 品質管理部門はWFベースでのメトリクスを要求すると辛い。POもあまり品質わかってないく、最初に握っても。。どうするか？
- 製造業（車、医療機器）はやはり品質気にする。チーム組成からQA担当メンバーも入り、インセプションデッキして、チームごとに決める
- メトリクスのトラッキング項目はWFとあまり変わらない。カバレッジとか。
- TDDだとバグがでない、そうするとこれまでのソースコード量単位の目標バグがでない
- やりかたも含めてQAと一緒に決めるしかない
- ルールで縛る。テストコードが無いプルリクは受け付けない。もしくはペアプロ必須とする。それにプラスしてテスターがいる。
- 品質保証部門に品質だけに責任を負わせると、イマイチになる。QCDを考えさせる。例えば経験としてPOになってもらうとかはうまくいった事例あり
- アジャイルの場合はプロセス品質を重視するというが多い。スプリント内でこなしたプロダクトバックログ数。多すぎても少なすぎてもよくない。
- CIが１週間に何回落ちているかなど。それもプロセス品質。
- V字モデルがわかっていないと、アジャイルも回せないよね？という議論もあり
- リモートワークが当たり前になっていくと、対話できないから、ドキュメントかかないといけないというものに逆にいっている流れも。チケットやチャットというものも結局文字伝達
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とか、転記マクロとか公開してくれませんか？とお願いしたが、現状予定なしとのこと。世の中にもいくつかあるようだとのコメントいただいたので、時間あるとき探したいと思いましたー。
懇親会は家族とのご飯予定があったので、帰りました。寒い日でしたが
イベントはアツかったですね！
運営とスピーカーにいつも感謝。
おつかれさまでしたー。
