Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
More from dcubeio
More from dcubeio (20)
新規事業でサイト立ち上げのアーキテクトをやった話
- 2. 自己紹介 • 新卒3年目 • 博士中退 • 脳波を機械学習で状態判定とか • 趣味や研究でプログラム書いてました • 基本的にC++ • 昔JJUGで別件の発表したりしてます • Java8移行から始めた技術的負債との戦い(JJUG CCC 2015 Fall) • ビズリーチサイトの開発についてJava6からJava8に移行した話
- 3. Bizreach Campus • 今回関わったWebサービス • OB/OG訪問のプラットホーム • 学生とOB/OGのマッチング • 2016年10月リリース
- 4. 目次 • 概要 • 技術選定について • 開発環境構築について • 開発メンバーへの導入について • 感想・まとめ
- 5. 概要
- 7. 構成について • モノリシックで構成 • 一つのサイトを一つのプロダクトのみで動かす • マイクロサービスだと時間と人的リソースが不足 • 学生側, 企業・OB側, Admin側の3つを想定 • 後に企業とOBで分離
- 8. 自分の仕事 • エンジニアが開発できる体制の確立 • 技術選定 • 開発環境の構築 • 雛形の作成 • 導入・開発を軌道にのせる ※ インフラやデザイン周りは他の人が責任を持った状態
- 9. 技術選定
- 10. 選定条件 意識したこと • メンバーのモチベーション • 生産性 • 他、表側はデザイナーが関わることを考える必要あり • 学生側, 企業・OB側
- 11. 選定について • こちらが提案し、メンバーがその中から選択・決定する • サンプルを作成 • メリット・デメリットの提示 • メンバーに選択させることでモチベーションを確保
- 12. バックエンド - 使用言語 • 決定: Java8 • メンバー全員が経験あり • 他の言語だとデメリットのほうが目立った • 候補: Scala デメリット: コンパイルが遅い, メンバーが未経験なので慣れるまでス ピードが出ない • 候補: Ruby デメリット: メンバーが未経験 & 自分含めガッツリやった人がいない
- 13. バックエンド - FW, ライブラリ これはむしろこちらがそうしたい、といった構成を提示 • Spring MVC • Spring Boot • Lombok • etc
- 14. Spring • メジャー・サブでプロジェクトが豊富 • 実装量を抑えることができる • Spring Boot を利用することで導入が楽になる • 今だと特に理由がない限りこれになる
- 15. Lombok • ボイラープレートコードを解消するためのツール • 自明だが省略できないお決まりのコード断片 • コードの記述量を減らすことができる • デメリットとして、コンパイルに時間がかかる • 既存プロジェクトで新しく導入する場合は正常に動作しない部 分が出てくる可能性があるらしいので、使うなら最初からのほ うがよい
- 16. フロントエンドでの選定について • 先にJSフレームワークを選定してからAltJS使うかどうかなどを 検討する形 • CSS関係はデザイナーの領域なのでそちらにおまかせ • ちなみにSCSSを使ってます
- 17. JSフレームワーク, ライブラリ • JQueryでゴリゴリ実装するのは避けたい • 作用が見えにくい • いくつかの候補から選択 • AngularJS • Knockout.js • React
- 18. AngularJS • フルスタックフレームワークなのでこれさえ入れれば一通りや りたいことができる • 情報が多く、利用例もちらほら • できることが多いので覚えることも多い • 選定時はAngular2の正式版が出ていなくて不透明
- 19. Knockout.js • MVVMフレームワーク • 簡潔で比較的覚えることも少ないが、最低限の機能はある • SPAにしたい場合は他のライブラリと組み合わせる必要がある
- 20. React • 流行っていて、メンバーが使いたい欲が高かった • ほぼJSなのでデザイナーが困る • テンプレートファイルを分けるなど回避策を色々試行錯誤したが、諦 めた • 他のFWと比べて敷居が高い • SEO考えるとサーバーサイドレンダリングをしたほうが安全? • ちょうどJS解析されるようになったくらいの時期
- 21. 選定結果 • デザイナーが関わるところはKnockout.js(+ Thymeleaf) • デザイナーにReactはきつい • AngularJSはAngular2の動向が不明瞭だったので見送り • デザイナーが関わらないところはReact • 一度は触ってみたい、とのこと
- 22. Knockout.jsを使った構成 • SEOや構成コストを考えてMPAで構成 • 1つの画面に1つのJS • 基本的に描画はサーバーサイドでできる部分はサーバーサイド で行う • 正直どちらに寄せても良かったので決めの問題 • JQueryについて • 原則使わないようにする • アニメーションなど、どうしても使わないといけないところだけ
- 23. Reactを使った構成 • SPAで構成 • React Router • Redux • JSXでプログラムを記述 • JQueryは原則禁止 • Adminなので凝った動きは必要ない
- 24. Java Script (AltJS) • ES2015 or TypeScript → Reactを使うのでES2015を採用 • ES2015 • class構文などモダンな言語の機能が使えるようになっている • ブラウザによって対応がまちまちなのでトランスパイラでES3に変換 • es-lintでコードの品質を担保
- 25. 開発環境構築
- 26. ミドルウェアの用意 • `vagrant up`だけで開発時に用いるmysqlやredisなどの用意が 完了するようにする • Bizreachサイトの開発環境のほぼコピー • とりあえず動くものを作ることを優先 • dockerの検討は後回し
- 27. タスクランナーについて • JSやCSSのビルドを行うタスクを記述する • Gulpを採用 • Gruntに比べて可読性や記述性で有利 • gulpfile.babel.jsにするとES2015で記述できる • JSのビルド部分はwebpackを採用 • 検証したところbrowserifyよりビルドが高速だった • MPAのビルドに対応している • 各ページ用のJSを食わせると、一つの共通JSと各ページ用のJSを出力する • 共通JSに出力されるのは共通でimportされているJSファイル
- 28. タスクランナーの構成 • 大本に一つのpackage.json（大本のpom.xmlと同じ階層） • ビルド用のスクリプトもそこに記述 • 一つのgulpfileでタスクを記述し、引数でプロジェクト名を指定 することで個別ビルドもできるようにする • 各プロジェクトにてymlで設定を記述し、処理を分ける • Knockout.js構成 or React構成 • 入力ファイルの指定、出力フォルダの指定 • etc
- 29. Knockout.jsの構成 • MPAなので成果物は全ページ共通のjsと各ページのjsとなる • フィンガープリント周りはバックエンド側で • 出力ファイル名に付与しなくても、Spring側でハッシュ値がファイル 名に追加されているように扱うことができる • VersionResourceResolver • /foo/bundle.js → <script src=“/foo/bundle-xxxxx.js”><script>
- 30. Reactの構成 • SPAなので成果物はindex.htmlと共通JSファイル • 出力するjsファイルにはハッシュ値を付与 • bundle-xxxxx.js • index.htmlにjsのファイル名を埋め込む必要がある
- 31. 実運用について少しだけ
- 32. 導入 • 導入手順やプロジェクト構成・画面の作り方などを資料にまと めた上で共有・軽い説明 • 当然のようにいくつかトラブル • node.jsがすでに入っていた人で消して入れ直したらうまく動かない • gulpのwatchがうまくいく人と行かない人がいる問題 • 何もしていないけど突然動かなくなった • etc
- 33. 運用 問題や要望にはすぐ対応する • デザイナー用にIDEを立ち上げなくても開発できるようなタス ク・スクリプトを追加 • ライブラリの導入作業 • pom.xmlの調整, JavaConfigの記述など • FWレイヤーな要件の実装 or レビュー • 他、色々ありすぎて正直あまり細かいこと覚えていない
- 34. まとめ
- 35. まとめ・感想 • 色々なことの調査・検証でインプット・アウトプットがともに 多い期間だった • プロダクトがどういった形に育っていくかを考えて構成を考え るのは楽しいが大変で時間がかかる • 実際にメンバーが手を動かし始めると、問題と相談と質問の対 応で自分の時間があまりない