公式サイト
受講内容
感想・メモ
感想とメモが混じっているので、読む時は注意 スピード重視で書いているので、内容や誤字脱字は大目に見てね!
jjug総会
メーリングリストからDoorkeperに移行。 会員数が多すぎるのと、スパムメールが増えてきたため。
最近のスパムメールは、苛立ちを覚えていた。
帰ったあと疑問に思ったが、メーリングリストはクローズされるんだよね?
残っていたら、スパムメールが飛び続けるのではなかろうかって思った。
非機能要件とSpring boot
非機能要件とは
主目的以外の要件。性能やセキュリティ機能など。
機能横断要件でとらえるのもありとかも言ってた。
これはIPAの定義だろうか?
どこから引用しているか見れんかった。
お客さんは、非機能要件がなんなのか分かりづらい。
その場に立ったことがないので、何とも言えんが。。。。
そんな場合は、IPAの非機能要求グレードを使うのが効果的らしい。
IPAが非機能要求グレードを出しているって初めて知った。
今回も合意のために利用しているようだ。
非機能要件にもいろろあるが、一部の要件は、フレームワークで対応することができる。それが、SpringSecurity & SpringBootActuratorなるものらしい。
Spring Boot Actuator
運用監視、活性保守をサポートする。 HTTP、JMXでアプリをモニタリング・管理できる。
インストールは、POIに依存性追加するだけ。
あとは、ブラウザでアクセスすればいい。 そうすると、JSONで結果が帰ってくる。
AuditEvents
認証認可イベント
health
アプリのミドルウェアの死活監視
独自の監視項目を追加することも可能
info
デフォルトではなにも表示されない
プロパティでinfo.があればそれを表示
git-commit-id-plugin
gitのバージョンを見れるようにしてくれる
gitバージョンを見れるのは良さそう
環境構築だけでなく、テストの障害報告とかにもバージョン情報はあると解析しやすいからね。
loggers
ログレベルの設定を確認できる。
特定のログレベルの確認もできる。
springbootでログレベルを変えられるので、効果が大きい。
metrics
cpu、メモリの情報が見れる exporterを実装するとredisなどにデータをエクスポートできる
trace
そのまま トレースログ見れる。
Spring security & other
パスワードポリシー
passay パスワードポリシーの作成ライブラリ
誤入力防止
terasolunaが提供している相関チェックアノテーションなるものがある。
ぶっちゃけ、Terasolunaって苦い経験しかなくて、あんまり使う気になれないのが、心情。
アカウントロック
spring fW @eventlistenerでイベントハンドリングする
データの秘匿
shaは辞めた方がいい。
sha系は速度優先のため、強度がそれほど高くない。
なので、ちょっと習熟すれば簡単に突破できるらしい。
passwordencoderを使うといいと勧めていた。
機密情報の暗号化
jasyptというライブラリを使って、暗号化すると楽らしい。
springboot-staterで提供されている
なお、シークレットキーはプロパティに入れないほうがいい。
入れたら暗号化の意味ないってのは、冷静にならないと分からなかったりする。
不正追跡・監視、トラッキングログ
サービスを跨いでも大丈夫なように、ユーザIDとリクエストごとに一意なトラッキングIDをもたせるのが一般的 横断的に追跡できる仕組みを用意しておくこと
Web対策
spring securityを使うことで、下記のことがデフォルトで対策される
感想
springbootはアプリを簡易に作成できるだけのものだと思ったが、運用設計がやりやすい機能もあったのは意外だった。
SpringBootは、まだ知らない機能がいっぱいある。
使い始めが簡単なので、試してみる。 → TODO
特にセキュリティは、知らないとまるで意識しないので、重点的に確認する。
知らぬ間に立ち見がいっぱいおった。 何気ないところでゴキブリを見つけた気分だ。 それくらいびっくりしたわ。
terasoluna押しやった。
ntt系の会社とお仕事しているのかな?って思ったら、主要取引先にあった。
長年terasoluna使っているっぽいね。
エンプラ開発におけるレガシーアプリケーションの巻取りとモジュール分割の戦い
www.slideshare.net
現状
Struts1系。
変更履歴をコメントアウトで保持。
既存のアプリがあり、新規アプリを担当。
既存アプリとは別口のアプリを作成した。
新規アプリを作るときに決めたこと。
レガシーフレームワークを引き継がない 従来の開発文化を引き継がない
変化スイッチ
なんのことかよく分からんかった。
意識が変わったきっかけってことでOK?
終始、頭のなかで「やる気スイッチ」のCMが駆け巡っていたわ。
ブランチ運用
運用ルールが明確に定義されていない
バージョンごとの開発ブランチを作るような感じになっていて、masterへのマージは、リリース時
テスト自動化
エビデンス納品対象の制約があって、自動化にも制約がかかってしまった。
単体テスト → junitのソース納品
結合テスト → excelにハードコピーをペタペタ
結合は、seleniumのラッパーライブラリを使って効率化を図っている様子。
どこでもやってそう。
エビデンス納品を、単体レベルでも要求してくるところではなくてなくてよかったね!と言いたい。
単体レベルでも要求してくるところが、現実世界でもある。
※おとぎ話ではない!
辛いだけで、お客さんがそれを見てないと、何のために作ったのか分からんって思ってた。
実際、見てないしね。。。
恵まれているほうだと思う。
テストフェーズ
ここの開発でやっていたテストフェーズの概念
開発時の課題
テストケースのレビューが辛い。
JUnitのソースが見づらいと、網羅性が分からない。
レビュー者の負荷が高いので、レビューしやすいようにテストケースを作ることを心がけた。
現在の課題
ロジックに沿ったテストになってしまっている。 仕様に沿ったテストケースにしなければいけない。
テスト環境デプロイ
ローカルに落として デプロイが手作業で煩雑 並行開発だとテスト環境が足りない
pushするとビルドが走る。 デプロイする場合は、ビルドされたもの選択してデプロイしている
大人の事情
大人の事情により、既存アプリの保守も担当することに。
大人の事情だから、たぶん既存アプリの保守していたチームが、疲弊したか、障害多すぎてお客さんに愛想つかされたかのどっちかだろうね。
デプロイの話を聞いていたが、あり得ない状態だった。
本番warを解凍 → classファイル差し替え → 再圧縮 → デプロイ
最初のwarは、eclipseでビルドされたものらしい。
闇を見た気がする。
そうとうに業が深い。
お客さん側に、システム開発に精通した人が居なかったのだろうか?って感じた。
新規アプリで確立・成功したデプロイ方法になるように、既存状態を改修。
その過程は、省略だったのが惜しい!
モジュール分割
当初、ベンダー単位でモジュールを分割していた。そのせいで、できていないことが結構あった。
1社体制でのモジュール分割
マージ最小化
依存の最小化
モジュールごとの非機能要件
古いアプリを徐々に新しいアプリに移植
→ 新しいモノリシックなアプリを作っているだけでは?
確かにその通り。
結局のところ、APIで機能を作らないと、いくら刷新してもモノリシックな状態のものが出来上がるだけだと思っている。
変化
成功例がでないと、変化は起こしにくい印象
一括再構築
信頼関係のもと、段階的に再構築するしかない 世のトレンドをどうやって適用できるかを考えておかないと、説得ができない
チャンス
最後のチャンスを使う話は納得
チャンスは誰でも平等にくるけど、それを掴めるのは、準備している人だけ
だから、常日頃から、流行のトレンドをどうやって適用していけるか考えておかないと、変えるチャンスが来ても、逃してしまう。
感想
エビデンスの話は、言いたいことが結構ある。
まだ、恵まれている方だと思うが。。。
本当に辛いところは、単体レベルでもExcelペタペタを要求してくる。しかも、説明のコメント付きで。
SIerに多い印象がある。
チャンスの話は、ビジネス書みたいな感じだった。
日頃から準備してないと、チャンスが来ても逃げるってのは、納得。
ものにできないで終わるか、そもそも気づかないか。
常日頃から神経を研ぎすませていないとダメだと思う。
SpotBugs(FindBugs)による大規模ERPのコード品質改善
Java静的解析ツール機能・動向
checksyle
ソースコード解析をコンパイルなしで実行
コーディング規約の確認が主目的
OSSでは割りと使われている。
理由は、いろんな人が開発に携わるため。
PMD
ソースコード解析をコンパイルなしで実行 問題の発見が目的 CPD(コピペ検出)機能がある。
FindBugs
SpotBugs
FindBugsの代価でデカくなってきた。
checker Framework
JSR308を利用する。 デファクト化しつつある。
Google error-prone
コンパイル時に動作 ソースコードの自動修正機能がある eclipseに非対応
Javaスキルの高い開発者がおおい
アノテーションの利用催促とspotbugs
Javaスキルにばらつきがある
checkstyleでコーディング規約を守るようにする
QA
Sonar lintがないのはなんで?
→ チェック内容の実態は、PMDとかFindBugsと変わらないので出さなかった。
複合的にルールを組み合わせるとこは素晴らしいと思っている。
コード品質が抱える問題と解決
開発している製品のアピールが長い! チェンナイってどこ?
デフォルト設定のまま使っていた
ビルドに時間がかかり、FindBugsを使うとパフォーマンス出ず、チェックをスキップする輩がいた。
きちんとやる/やらないを考えて適用を考える。
個人的にはデフォルト設定で運用して、変えてくでもいいと思っている。 明確な基準がある場合は、別だけど。
FindBugsが遅い
G1GC→回避できない
そもそも使うメモリが多ければ大丈夫だけど、それをするのは大変
他にも何か言っていた気がするが、ちょっと意識が飛んでた。。。。
たぶん、別の誰かが憑依したんだと思う。
文型さえおさえれば英語を読む力は上がる!
ポイント
- 辞書の意味を当てにするな
- 文脈に頼りすぎない
- 例外を気にしすぎない
- 雰囲気で読まない
Google翻訳するなって言ってなかったからOKでいいよね。。?
5文型
というか、「文型」って書いて「ぶんけい」って読むことに驚いた。
てっきり誤字かと思ってたわ。。。
- SV
- SVC
- SCO
- SVOO
なんか、SVって言われると頭が痛い。。。
なんかの業務でSVってのが居た気がするが、なんだっけ?
商流系だった気がする。
文型については、意識したことない。
気をつけること
日本語の単語のまま使うのはダメ。
名刺っぽい単語でも、他動詞になるものがある。
introduction of project jigsaw
言っていることは信じないでくださいか。。。
jigsawがどうなるか分からないってことだろうか?
仕様承認の投票で、SE9は通ったけど、jigsawが通らないっていう謎の状態なのね。。。
red hat, ibmが反対
だから、信じないでくださいにつながるのか。
背景
いつものjar地獄とhadoopのクラスパス
Jigsawの話でココらへんのことを知らない人は居ないと思うので省略。
module
moduleかどうか判断する場合は、module-info.javaの存在有無を確認する。
ある→モジュールとして使う
ない→モジュールとして使わない
module-infoに書くもの
- 依存関係
- 公開範囲
module-info.javaの置き場
トップレベルに書く
module-ingoの内容
依存関係
requiresで指定する。
java.lang → 必ず使うので、記載しなくても依存に含まれていると思って良い。
publicは、exportしない限り、以前のpublicと同じではない。
モジュール化で公開有無が変わったため、Class.getInstanece()が使えなくなっている。
モジュール化したい場合
jdepsを使って、依存を見極める
jdepsについては、JavaDayTokyo2017のまとめにも出てきたので、よかったら見てみて
jreの自作
–genarate-module-info をjavacにつけると、独自のjreを作ってくれる
モジュールの扱い
自信はモジュールで、モジュールじゃないものを使う
automatic moduleを使う
安易なモジュール名になってしまうのが論点になっている。
automatic-module-nameを付けましょう的な流れになっているが、どうなるかは分からない。
QA
mavenとmoduleは、どうやって整合性をもたせるのか? → まだ決まってない
メタ情報なのにjavaなのはなんで?jsonじゃダメ → jsonbが入ればそうなるんじゃない?
javaでjson使うのは面倒くさいので、javaでいいんじゃない?
module化した場合としない場合の起動のち外 → そんなに変わらない。モジュール読む量によるかも。
moduleのバージョン → いまのところ掛けない
スーパーパッケージ → なくなった。
Java8コーディングベストプラクティス & NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する
NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する
jmxでデータを収集して、influxdbに突っ込み、grafanaで見る。
深層学習の話は、ある程度、知識としてあったので、なんとかついて行けた。
教師データは、たしかに教師データが正解だから、深層学習する意味ないよねってのは分かる。
深層学習を追い求めるロマンティストだったんだね。。。
Java8のプラクティス
基本的に、分かっているつもりの内容だったので、あんまり聞いてなかった。
たぶん、意識飛んでたと思う。
マチコ&河村の怒り新党 〜真の最終回〜
本家終わりましたからね。
初頭のトークは何を言っているかわからなかったが、内輪ネタかな?
場所を選ばないはずのITなのに東京開催の勉強会に腹が立つ
東京くれば? もしくは、自分で内輪で開催すればいいのではなかろうか?
実際に地方にいる人の意見だと、開催できない最大の要因は、金より人材な感じっぽい。
やっぱり数は力なんだね。
動画配信要因は、有志で募集中 勝手にやるのはNGなんで、声かけてね!
人いっぱいいるから、動画撮影好きのヤツはいる気がする。
それが山本さんだけなのかな?
CCCを地方開催するには、金の問題と人が集まるかが問題な気がする。
個人的には、関東でなければ、行かないと思う。
自分の上長の期限を伺うために、自分の部下に無茶振りする上司に腹が立つ。
そもそも昔からある。 企業文化として根付いている気がするので、このまま行けば仕事をしていれば出世できると思うよ?
周りに期待してもしょうがないから、転職すれば?って意見が最終だった
Javaの人は別の言語を勉強しろ!
この人はJavaしているのか不明の状態でスタート。。。
自分は、Python勉強中、Typescriptを業務で使用中。Javaは使ってないんだよね。。。
別の言語を勉強してもいいけど、Javaから多言語でも通用するような普遍的な知識を得られているから、結局他の言語勉強しなくてもいいかな?って思う。
一つの言語に習熟したら、他の言語もだいたい通用する。
現に、自分はTypescript知らなかったけど、全然問題なく使えているもの。
確かに、言語で何をしたいかが重要だね。
言語は手段であって、使えることが目的になると、ビジネスが成り立たなくなるような気がしないでもない。
「こういうこと言うからには、もちろんお前は複数言語を同じレベルで使えるんだよな?」って、喧嘩腰で聞きたくなる。
同僚が全く勉強しません
同じネタだね。。。
別にいいんじゃない?
自分が必要性を感じてないなら。
外部から働きかけても、内部からやる気を起こさないと、無意味だと思うんだよね。
その環境なら、転職するしかないね。
環境に不満を感じているなら。
勉強とは、周囲とのギャップを埋めるための勉強ってのは、納得の意見だ。 周囲が勉強しないことに不満を感じているなら、それは自己満足ってのも納得。 上司は、だいたい自己満足で勉強しろって言ってくるからな!
個人的には、周囲が勉強しないのは、むしろ好環境ではなかろうか?って思う。
だって、自分は勉強して優位に立てるんだから。
むしろお願いしたい。周囲の人に勉強しないでくださいって!
周囲との差別化も測れて、上司受けは好調にもなるしね!
ずっと自分の優位性が確保できる環境って素晴らしいと思うんですよ。
出た意見として、社内で少数でもいいから勉強する土台を作って、そこから徐々に変えて行くのがいいのではなかろうか?って意見もあった。
やった身の上からすると、だいたい付いて来ない。
上から圧力かけるかしない限りは、動かない。
老害が許せません
居場所を守るためにコミュニティを作ったり、昔の自慢話するのが許せない。
前回もあった気がする。
自分はぼっちなので、特に思うことはない。
一番気になるのは、電車で喋っている2人組で、上長っぽい人が自慢話が一番許せんと思うな。
なんか、スゲー偉そうにしていて、腹立たしく思うことが多々ある。
自社は、特に関係がないので、なんとも感じない。
我慢して時間が流れるのを待つしかないのか。。。? あれだ、電話かけてもらうアプリを使って、その場を切り抜けるってのが優良策かな?
新しいことにチャレンジしたいなら、老害を論破するしかない。
論破も、完膚なきまで。
そこまでできないなら、自分も害悪になっていると思うしかないね。
怒り心頭なこと
最後募集かけてたけど、人前でそういうこと話すのは、スゲー雰囲気悪くするから、名乗りでないと思うんだよね。。。
帰りの電車の中で思ったが、いくつかあったわ。
- 言っていることが矛盾しているPJリーダーに腹が立ちます。改善案を出せと言ってきたので、出したらみんなが聞いている前でディスる所業が始まりました。なんとか耐えましたが、その後、改善案を出す人は居ませんでした。このリーダーは本当に改善案を求めていたんでしょうか?
- 勉強しろという上長に腹が立ちます。上長は大して勉強していないくせに、配下メンバーには勉強を強いてくる。ここは、自分がやって言える立場になってからいうことだと思うのですが。。。
- 満員電車に腹が立ちます。満員状態で乗ろうとしたら、おっさんがDio並に「無理無理無理」って連呼してきました。乗るのを辞めたら、後ろから若い女性が乗り込もうとしました。その女性は乗れたのですが、その時は「無理」って言わないんだな。死ねばいいのに。
- 長いものに巻かれる上司に腹が立ちます。アーキテクチャの概念から、機能配置はこうあるべきと進言したのですが、上長で却下されました。理由を説明しましたが受け入れてもらえませんでした。その後、エンドユーザーのシステム開発のアーキテクトレベルの人が、まったく同じ指摘をしてきたら、その指摘は反映されました。なぜ?
あんまりシステム開発とかに関係ない気がする。。。
次回
かりそめになるのか。
かりそめ天国は、はっきり言ってつまらんからな。。。
ちょっと不安が募るわ。。。
Sli.doとか使って、匿名で意見もとめないと、発言しにくいんじゃなかろうかって感じる。
ただ、節度ある発言ができるかは疑問が残るけどね。。。
懇親会
LINE株式会社の寿司提供。
ありがたや~
寿司も、ワサビ付がデフォで良かった。
今のワサビ抜きの考えは間違っていると思うんですよ。
特に誰とも話すことなく、ある程度食して終了。
思ったけど、みんな顔赤すぎではなかろうか?
こんなに弱い人が多いんだなって感じた。
全体通しての感想
今回は、午前中(総会までかな?)は、人が全然いなかったのに、一気に増えた。
1000人もあのフロアでうごめいていたのかと思うと、驚愕。
全員倒したら、無双になれる!ってどうでもいいことを考えながら懇親会で食べてました。
あと、全員顔見知りなのだろうか?
自分、超小企業から来ているので、単独で参加している。
なんかみんな顔見知りみたいな感じで、ちょっといづらさは感じた。
いつもなら感じないんだけどね。流石に人が多すぎて、感じずにはいられなかった。
ToDo
- Jigsawを試す
- そろそろカンファレンスに登壇を考えてみる
- Spot Bugsを試してみる
- Google error-proneを試してみる
- Spring Boot Actuatorを使ってみる
- Spring Securityを使ってみる