今年もきたぜ、JJUG CCC。
去年のFallはボランティアとして参加しました。
今年はがっつりセッションを聞きたいので一般参加です！
このエントリーの体裁を整えている時に、
AWS Summit 2017 Tokyoに参加していました。
イベントラッシュと業務で忙しいこの頃、皆さんお元気ですか。
7月1日はDevelopers IOに参加したいとも思っています。
classmethod.jp
最近ブログのエントリーが遅れがちなことについて
(コーディングの)アウトプットを最近優先しています。
ですので、インプットの内容をブログに残すことが
遅れがちになっていると思います。
ですので、行ってきたレポートはなるべく
その場で書いていき、スピードを上げていきたいと思います。
今回の内容は試しに、赤が重要なインプット、青を所感で記述してます。
レポート
非機能要件とSpring Boot
- 「機能要件」以外の要件が「非機能要件」
- 「非機能要求グレード」←IPAの資料がまとめられていて便利
- Spring Boot Actuator → 運用・保守性に貢献
- 運用監視、活性保守
- JSonViewプラグインなどで整形すると見やすい
- 運用中のログレベルの変更が可能なのはすごく便利だなぁ。最高じゃん。→でもこれActuatorが必要なの？
- メモリは圧迫するかも
- pull型基盤なので、自分からデータを取り出すような仕組み
- Spring Security & Others
- PassayというパスワードポリシーをBeanValidationで使うのが便利らしい。
- SHA*ではなくBcryptまたはScryptを使うべきなのかー！
- jasyptでプロパティファイルを暗号化することもできるのか。本当に勉強になる。
- 復号化のキーは環境変数などに隠しておく。これはいいな！
- 不正追跡・監視（トラッキングログ）
- トラッキングIDを付与するとトラッキングが楽になる。
- TERASOLUNAのライブラリで存在している。
- Spring Data JPAによる監査ログ便利だなー。
- Spring Securityのログイン情報を登録することができるんだな！
- JPAの@MappedSuperclassも忘れずに覚えておこう。
- Spring Securityなら下記を標準で保護！
- セッション固定攻撃対策
- クロスサイトスクリプティング対策
- セキュリティヘッダ
IPAの非機能要件グレードは参考になりすぎた。
業務でも活用していきます！
www.ipa.go.jp
Vue + Spring Bootで楽しくフルスタック開発やってみた
Vue.js + Spring Bootで楽しくフルスタック開発やってみた
- JAX-RS + 静的HTML + Knockout
- Knockoutによる双方向データバインディングって面白いなー。
- JQueryはpull型
- 登壇者が担当した業務の要件
- Android・iOSの両方に対応する
- 機能的にはWebアプリの域を脱しない
- なのでCordovaを選択→Webビューを使ったフレームワーク。
- Vue.jsを使うと双方向バインディングができる。
- ネイティブアプリっぽさを出すためにSPAを目指した
- vue-router 2 → ルーティング
- Vudex → Flux実装 → SPAで、状態を保持するのにかなり便利だったらしい。
- axios → HTTPクライアント → ajaxの機能のため
- npmとwebpackの導入
- npm → JavaでいうMavenやGradle
- webpack → build.jsを生成するためのツール的な。プラガブルなコンパイラ。
- webpack dev serverが便利らしい。 → コード変更を検知してビルドや、ブラウザの自動リロードなど。
- Vueの便利なもの：Chrome拡張
- Virtual DOMの状態や、バインドされている値を確認できたりするので便利。使うべし。
- Spring Bootとビルド
- ビルド済みjsをSpring Bootでホスティング
- 登壇者の理想のフレームワーク
- Spring Boot, devtools
- Spring MVC
- Doma
- Vue, axios
- Gradle
- npm, webpack
- Selenide
- クラス設計：重要なデザインパターン
- Observer
- Iterator
- Visitor
CSS Grid Layoutはかなりすごいらしいので、触ってみたい。
spring boot devtoolsとwebpack dev toolsでのHot Reloadingな開発面白そう！
Javaエンジニアに知って欲しいRDBアンチパターン
- データベースの寿命はアプリケーションより長い。
- 後々に苦しみを生むようなパターンをアンチパターン
- アンチパターン1：
- デリートフラグとかの、フラグ系に1と0以外がある。
- アンチパターン2：
- memo, memo2, memo3
- 不適切な名前ではデータベースのテーブルの関連性や意図が理解できない。
- memo, memo2, memo3
- アンチパターン3：
- 論理ID(途中2桁は都道府県コードを表すような例) → データにロジック埋め込むな。
- アプリケーションを変えずにRDBのトリガという機能を用いて移行させることができる。
- 理想のViewを作って、参照はこっちとか進めていく。
- アンチパターン4:強すぎる制約
- 変更が大変→時間が経てば立つほど状況が悪化
- データベースほっておいても直らない。
- そのためにRDBの機能を活用する。→ しかしそれが裏目に出ることも。
- RDBの機能に依存しすぎると裏目になることがある。
- （※ストアドは更新する時にデータベースの停止が必要になる！ -> だからあまりストアドにロジックを持ちすぎないほうがいい。）
- 成功体験のバイアスや、失敗体験のバイアスが、最適な手法の選定を妨げる。正しい設計を学ぶ方法とは？
- テストコードはリファクタリングのために必要。
- インフラのリファクタリングはモニタリングから？
- 賢者は過去に学ぶ
- 一度作ったDBは消せない → だからこそ設計が大事
- データベースの死はサービスの死 → 解決できる人は英雄
- DBの問題は忘れた頃にやってくる。
- サーバーの問題は休日にやってくる。
- アプリケーションの問題は納期前にやってくる。
- 脆弱性の発見は連休中にやってくる<- New!!
SQLアンチパターンを読むことを登壇者の方がおすすめしていたので、
読みたい。会社にあった！
www.oreilly.co.jp
Introduction of Project Jigsaw
www.slideshare.net
- Moduleに依存性と公開範囲を書いていく。
- メタ情報があるのがModule.それ以外がjar。
- module-info.javaにmavenみたいにがんがん書いていく。
- 依存性
module net.jitb.hello {
// 依存性の追記
requires javafx.controls;
}
- 公開範囲
// puckage export
exports net.jitb.hello;
- 新しいものを作るのは簡単。
- 古いものを混ぜるのは大変。
- export書かないと、publicにならない。
- なので、java9で使えなくなったライブラリがある。
- class.getInstanceとか。
- javaコマンドに、--オプションがたくさん増えた。
- ※javac生で打つことはほぼないよね。
- IntelliJ IDEAは既にJava9に対応している。
execution( --module-path mod ~
- 標準モジュールの確認
- java --list-modules 現在73個くらいらしい
- java., jdk., javafx.ではじまるものがある。java.で始まるものが使えるもの。
- カスタムJRE
- jlinkを使って自分が欲しいモジュールだけを定義できる。
- 自分が持ってるモジュールもパッケージング化してカスタムJREの作成ができる。
- マイグレーションをどうするか
- ただのJarファイルをモジュールにしたい場合に、ライブラリが何に依存しているかをjdepsコマンドで確認できる。
- Automatic Module
- モジュールパスに置くだけで、Automatic Moduleとして扱ってくれる。
JigSawはJava9リリースまでに変わる可能性がまだまだあるので、
今後の動向を見張っておく必要があります。
個人的には依存性が分かりやすくなるのは便利だと思うので大変興味があります。
Engineers can change the world ~ "世界"で活躍するエンジニアになるために
- 自分の中に本能的に発生している差別（血液型や性格などで人を判断するような偏見）というのはよくない。
- それが、"my unconscious bias"（自分の無意識の偏見）
- 登壇者の方は、富士ソフトABC→SUN→Oracle→Microsoftというすごい経歴を持つ人。
- 中学時代とか、高校時代とかに英語は全くダメだったらしい。
- 逆に日本語の文章を翻訳して見ている外国のエンジニアだっている。
- 今は自分たちが思っている以上にグローバル化している。
- 39歳でJavaを作った生みの親を見れば、35歳定年説なんて関係ない！というかありえない。
- 学び続ける姿勢が大事
- クリント・シャンク
- 年齢関係ない
- やはり英語は重要。
- 自分が持っているバイアスをいかに取り除くか。
- そうすれば、もっと他人と話しやすくなる。みんなをリスペクトしていく姿勢が大事。
- 目が不自由なマイクロソフトエンジニアの話がすごい。感動した。
- これを見ると、本当にITが世界を変えると思える。
- love your self
- love your peers
- love your work
- 自分を変えられのは自分だけ。
- inputが多い人はアウトプットをしていこう。
- ブログやSNSから、登壇へ。
- OSSへのコントリビューションだったり。
- 日本人であっても世界で活躍できる場所は、たくさんある。
- 夢は必ず叶います。
- 夢を持って成長すれば、世界は決して遠くないと思う。
- embrace community
- embrace diversity
- embrace inclusion
ハックで生きる：オープンソースで会社を興すには
www.slideshare.net
- オープンソースのビジネスモデル
- プロフェッショナル・サービス
- 正しい使い方の指南
- 個別企業向けに追加機能の請負開発\
- 製品版
- 作れば勝手に売れるものではない。
- OSS版で十分だと思っている人が大半。
- 企業のサイズ、ポジショニング、営業が必要
- プロフェッショナル・サービス
- SaaS
- 価値の上限や、顧客個別事情への対応など
- サポート
- それなりの体制・規模・仕組みが必要
- 知識のある技術者を雇わないといけない
- コミュニティから人を雇える魅力がある。
- 優秀な雇うべき人を探すのは簡単
- 働き方も癖も性格もわかっている
- OSSの貢献にも限界が
- 趣味の細切れの時間や本業の片割れの時間で出来ることには限界がある
- 複数のコミュニティ開発者が共同作業するのは難しい
- 時々即売上になる？→おまけとして引き抜き前の会社から売上もらうとか（笑）
- 欠点もある、
- 開発者の中に葛藤が。
- 自分の時間？仕事の時間？
- 会社がやりたいことと、自分がやりたいこと
- プロジェクトを横取りしようとしていると映る危険性?
- 主要開発者がみな同じ会社の従業員になってしまったら?
- プロジェクトの開発者が目減りする
- 製品開発に回ってもらうとその分OSSに穴ができる
- ブランド・商標・法律関係
- 商標が誰のものになっているのか、確認が大事
- 昔HUDSON問題とかもあった。
- 商標が誰のものになっているのか、確認が大事
- お金持ちになりたいんだったら、オープンソースの会社なんか作っちゃいけない😁
- オープンソースは無双
- 開発手法が最強
- 組織が力を結集しないとできないこともある。
- 一人でできる仕事と一人ではできない仕事との違い。
- 開発者だけでは実現できない仕事。
- 企業がオープンソースに貢献することで、オープンソースコミュニティの存在も大きくなる。
- 開発者以外のスキルセットの人を集めることができる。
- デザイナー、テクニカルライター、イベント・・etc
- 企業の参加で初めて得られるリーチがある。
- 他の企業の参加も促せる。
- Blue Oceanすげぇ！
結構ぶっちゃけ話が多かった気がしますが(笑)。その度に笑いをさそってました。
Jenkins生みの親の方が登壇していたこともあり、その一つ一つの言葉に説得力がありました。
個人的に見たかったセッション
コーヒーカップワロタw
Google I/O 2017でKotlinがAndroidの開発言語として公式にサポートされるようになって、
自称エヴァンジェリストの方が調子に乗っているようですw
こういうの好きw
成子天神社
ベルサール新宿のすぐ近くにある神社。相変わらずピンキーなピンク色してるなw
冬にまた来るから、その時にまた拝みにきたいと思います！
以上、JJUG CCC 2017 Springのレポートでした！
参加者の皆さん、お疲れ様でした！
