JJUG CCC 2022 Fallにオンラインで参加しました
今までは視聴して手元のメモに書き留めるのみだったのですが、 折角オンラインでセッションをしちょいうできるのなら、見ながら記事を書いてしまえ、と思いやってみます。
AWS環境におけるSpring BootアプリケーションのCI/CDをCircleCIで構築した話
視聴を決めた私の動機
- CI/CDに興味があるがどうやるの？
- 配属先でCodeCommitを使用しているので、導入ハードルは低いので自分にもできるかなあ
メモ
アプリの構成
- AWS × Spring Boot × CircleCI
- EC2にてSpring Bootアプリを配置
- ECSにてSpring Batch/Spring Boot
- Gradleのマルチプロジェクト
CircleCIの構成
- DBUnitでCircleCIにてMySQLを起動して実行(H2と微妙にことなるのでDBUnitが通らない)
- SpotBug、CheckStyle、Unitテストの実行は並列実行
自分の感想
- 調べたら、CircleCIって有料なのね。でも考え方は他の何を使っても一緒だろうし、お手本になるかも。
- テストデータ投入は別途手で行うとあった。事故の元だということで。もう一度、その部分だけ聞き直したいかな。
聞きながらググったもの
Git 未経験者が GitHub Actions で CI/CD できるようになるまで
視聴を決めた私の動機
- CI/CDに興味
メモ
- ブランチ戦略を明確に定義しておく事が肝要
- 無料分を枯渇させないのは大事(有料でも予算的に許される範囲で使う)
自分の感想
- 新しいことの導入の苦労はあるよなあ。調査検討して、あとは教えて習熟してもらっての流れはちゃんと作らないと回らないなあ。
LINE NEWSにおけるJava移行の5年間の歩みとこれから
視聴を決めた私の動機
メモ
自分の感想
- トラフィック大きいな……。限られた人しか使わない業務アプリケーションしかやったことがないから、どう対処しているんだろう。負荷・性能試験とか。
- 負荷によるRedisのレスポンスタイムアウトの件、解消までの道のりが難しい……。すごいなあ。ググって質問サイトを見るだけではなく、公式ドキュメントを読み切る力はやっぱりつけておかないとだめだよねえ…。英語の勉強しなきゃ。
聞きながらググったもの
入門：テスト技法とJUnit
視聴を決めた私の動機
- テストを書く文化を浸透させたいのでそのヒントに
メモ
- JUnit オリジナルの作者 -> Kent Beck、Erich Gamma
- 新規にテストを書くならJUnit5
- すべてを4 -> 5に書き直すメリットはない
- Extension
- テストしやすいコード！
- メソッドはなるべくvoidにしない
- 副作用のあるメソッドはなるべく少なくする
- 外部システムにアクセスする箇所はなるべく少なくする
- 日時、ランダム値は引数で渡す
自分の感想
- 自分が知っていることの復習だなあ、という感じ
- 聴きながらカバレッジ100%は目指したいけど、境界値はレポートに表れないから結局ソースレビューしないと良くないよね
- あれ？うちのチームソースレビューしてないよね？？？
Java開発ツールのあれこれ ～便利そうなツールを色々集めてみた～
視聴を決めた私の動機
- 知らないツールでよさそうなのがあれば導入したいなあ
メモ
- SpotBugs使いたいけど、コーディング中に毎回実行する営みにするか、CIができていないとだめだなあ
- Error Prone
- ESLint ‐ Jenkinsのトレーニング、資格なんてあるんだ！
自分の感想
- ArchUnitってあったなあ。別のセッションというか、別のイベントで知ったが。
Javaの入門が終わったら何の勉強をすればいいの？
視聴を決めた私の動機
- さすがにJava初心者ではないけれど、業務で必要になったなど、行き当たりばったりに学習をしているので、もっと指針を決めないとこの先つらいかなあ、と不安になっているので。
- 業界に入るのが遅かった & あまり開発に関われなかった & 不安になった割に個人学習が足りない自覚もある
メモ
自分の感想
- 「期限はないのでじっくりやりましょう」が心強かったです…。自分に焦りがあるので。
宿題
簡単に喋れる程度には理解しておきたいなあ。 記事にしたい。
気になるスライド資料やブログ記事のまとめ
命名とか
↑こちら、データの名称の参考に。
Docker
Docker怖い。書籍買って読んだけどよくわからないんだもの。 でもそろそろやらないと。
テスト関連
↑参加していないけど、こちらのイベントで発表されていた資料。 Javaで同じ考えを適用できるものも一部あるので貼付。
↑の人が合わせて読むと良いとしている資料。 speakerdeck.com
Gitワークフロー
気になる。 単なるバージョン管理にしか使っていないので。
Linuxコマンド関連
コマンドはある程度分かるけど、ある程度でしかないので。
DDD
2022 JJUG CCC Spring メモ
視聴しなかったけど、こちらのセッション資料で気になる点が。
39ページ目で、「BCryptPasswordEncoderが遅い」「BCryptPasswordEncoderを使用せず自前実装に切り替えたところ1500msから350msまで改善」とあるけど、暗号化やハッシュ化回りは自前実装しないのがセキュリティ的には安心なんじゃなかったっけ？
これこれ↑。 徳丸浩さんのツイートもあるし。
で、BCryptPasswordEncoderが遅いならPbkdf2PasswordEncoderかなあ。 SCryptPasswordEncoderはいくつか警告もあるし。
自分でログイン認証作るときは考慮しよう。
Swaggerに触れる
最近記事を書いていないことに気づいて慌てて書く。
「何だこのyaml？」から
業務で他プロジェクトのドキュメントをあさっていたところ、ExcelやWordのドキュメントを期待していたのに.yamlのファイルを2～3個発見。
どうやらAPIの定義が書いてあるようだが、テキストエディタで開いたままだと何が書いてあるのかさっぱりわからない。
で、担当の方に聞いたところ、Swaggerを使用して書いたものだという。
Swagger Editorを使ってファイルを開くと、なんかいい感じのドキュメントに見える！ナニコレー！
ということで、軽く調べて記事にする。
OpenAPIというもの
APIを記述したり文書化するためのオープンソースの書式だそうで。
もともとはSwagger仕様だったものが、OpenAPIとなり最新バージョンは3.0.0。
定義の記述はJSONまたはYAMLで記述可能。
おすすめはYAMLとのこと。
そもそもYAMLがよくわからん
Spring の教材の、設定ファイル関連の説明で見たけどそもそもどういうものなの？
ということで。
説明は上記リンクにあったのでざっくりと読んだ。
「"」とかそもそも書かずに済むやつなんですね。
業務で見たファイルは結構「"」入ってたなあ。
JSONやXMLと比較して読みやすいし、コメントも書けるしシンプル！ということのよう。
分量が少ないけど、今日はここまで。
学習したいこと、考えをまとめておきたいこと
開発環境について
Vagrant + Elasticsearchのローカル環境構築の手順ができたのと同時に、業務にてElasticsearchのSSL対応(HTTPS接続)の設定を完了。 あと、Elasticdumpの使用方法を理解して、実際に動作の方法についてメンバーに展開した。 ちょうどよくKindle Unilimitedの対象にこいつ↓が。
内容的にちょっと古いけど、バージョンは業務で使用しているものと一致するのでデータ構造の理解にかなり助かった。 クエリはSQLのようにはまだ自分で書けないけど。 ドキュメント、ドキュメントタイプ、インデックス……、など構造を書籍で理解したおかげで、先ほど書いたElasticdumpで取り込もうとしているデータがどんなものなのかの理解に役立った。
今回の業務で作るアプリの環境をまるっと作れるように用意はしておきたい。
AWSによるサーバーレスアプリ開発について
これも業務、というか課題?でやることになったもの。 業務ではないので厳しくはないが、未知のもの過ぎて手が止まる止まる。 また、スクラム開発でこれを行うものだから、自分の振舞い方からわからなくなってしまい戸惑っている現状。 モブプログラミングなのに自分主導で自分でがつがつ作ってしまっている。。。よくない。。。
とにかくAWSがわからなすぎるのでプライベートでAWSアカウントを取得。 無理のない範囲でいろいろ触ってみることにする。
会社の研修でAWSの研修受けたけど、意味が分からな過ぎて全然役に立ってないという悲しみ。
DDDについて
興味本位。 とりあえずもちこちゃん↓購入。 物理本で欲しかったんだけどなあ。 個人で出しているものだから入荷する期待はできなかったので、とりあえず電子書籍で購入。 暇なときに読むことにする。 物理本出たらお布施として買おう。
テストソースを書いて行う単体テストを定着させる活動
意識しないとたぶん全然現場に定着しない、というかそもそもやろうとすらしない。 よくない。 次回の開発から導入しましょうよと持ち掛けるも、いきなり導入して失敗したら困るから小さな改修から導入しましょうよと言われてしまった。 小さな改修、いつどこであるんでしょうか。 毎回そこそこ大改修じゃないですか。
正直、テストを書く意識のないソースの改修でテストケースを書くよりも、 最初からテストケースを書くつもりで一から作ったソースに対してテストを書くほうが万倍楽なんですよ。
ということで自分の意見を通して安心してテストを書くプロジェクト・チームにしたいのでそのためのプレゼンをします。
プレゼンに向けて整理すべき、やるべきこと。
- 各テスト段階におけるやるべきことの整理
- 改修ソースにテストを書くつらさと新規作成ソースにテストを書く気楽さの具体的な比較
- じゃあどう書けばいいのさ→実例としてアプリを作成し、Githubにて公開
マジで今後の修正スピードの向上のため、急ぎ取り組んでいくことにする。
