WEBフロントエンドの学習の仕方

Slide 1

Slide 1 text

WEBフロントエンドの学習の仕方 1 2019/10/08 【生配信】フロントエンドの学習の仕方【サポーターズ CoLab】 https://supporterzcolab.com/event/956/

Slide 2

Slide 2 text

2 姫野滉盛所属 ● 株式会社ドワンゴ SNS ● GitHub@Himenon ● Twitter@himenoglyph 自己紹介

Slide 3

Slide 3 text

3 1. 新しい情報を消化するまでのルーチン 2. 情報収集の巡回と消化に必要な知識 3. WEBフロントエンドの背景知識（ざっくり版）アジェンダ

Slide 4

Slide 4 text

4 ◉ スライドを公開しているので、先読みOK ◉ 気になるところはコメントをください ○ 可能な範囲で応えます ◉ 誤字脱字や間違っている場所があれば遠慮なく指摘してくださいお願い

Slide 5

Slide 5 text

◉ WEBフロントエンド初心者 ◉ 学習方法がよくわからない・途中挫折しがち ◉ 「ドメイン駆動開発」という言葉に馴染みない ※発表したところ、Feedbackの中で難しいというご意見をいただきました。WEBフロントエンドという職種があるようなチーム構成だと必要になってくるような知識として記述してしまっているため、バックエンドとフロントエンドの結合度が高い状況を想定し損ねています。フロントエンドの柔軟性を取り入れていきたいというような状況に置かれた場合の一つの指針として中盤以降は読みすすめると良いかもしれません。 5 本スライドの対象

Slide 6

Slide 6 text

新しい情報を消化するまでのルーチン自分自身の行動の振り返り 6

Slide 7

Slide 7 text

1. GitHubを開く 2. 気になるRepositoryがある 3. READMEを見る a. → 面白そうだったら★ 4. ★動かす a. → 面白かったら★ 7 新しい情報を消化するまでのルーチン GitHubで発見パターン

Slide 8

Slide 8 text

GitHubのライブラリ巡回パターン 1. GitHubを開く 2. JavaScript系のライブラリの場合、package.jsonのdependencies, devDependenciesを見る 3. 知らないライブラリを片っ端から開く 4. npmjsで利用数、Dependentsを見て、利用数の多いものから調べていく 5. 作者をフォローする a. GitHubのタイムラインが充実する 8 新しい情報を消化するまでのルーチン

Slide 9

Slide 9 text

1. Twitterを開く 2. 良さそうな情報を発見する a. 有名なライブラリの作者やメンテナーの発信 3. だいたいGitHubへ飛ぶ 9 新しい情報を消化するまでのルーチン Twitter巡回パターン

Slide 10

Slide 10 text

まとめ ● 自分のネットサーフィンの巡回経路に新鮮な情報が取り入れられるようにしておく。 ● 有益な情報源を埋もれさせないようにする。 ● 見つけたときに手を動かすようにする。 10

Slide 11

Slide 11 text

情報収集の巡回と消化に必要な知識 11

Slide 12

Slide 12 text

12 フロントエンドの学習の指針 ● WEB DEVELOPER ROADMAP ○ https://github.com/kamranahmedse/developer-roadmap ○ https://roadmap.sh/ 何をどこで使うのかを具体的に紹介していきます情報収集の巡回と消化に必要な知識

Slide 13

Slide 13 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 13 情報収集の巡回と消化に必要な知識

Slide 14

Slide 14 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 14 情報収集の巡回と消化に必要な知識

Slide 15

Slide 15 text

私の解決方法：テンプレートジェネレーター（ボイラープレート）もしくはcreateapp系のCLIを利用する理由： ● 設計・開発に時間をかけたい ● 環境構築については、相談相手がいること or 十分な検証時間が必要。挫折しないような環境構築を最初にしておくことがキモ 15 情報収集の巡回と消化に必要な知識 - 環境構築をする

Slide 16

Slide 16 text

フロントエンドフレームワークを利用する場合 ● React ○ create-react-app（https://github.com/facebook/create-react-app） ● Vue ○ Vue-cli ● Angular ○ Angular-cli テンプレートジェネレーター CLIにバンドルされているタイプ 16 情報収集の巡回と消化に必要な知識 - 環境構築をする

Slide 17

Slide 17 text

● 自作ジェネレーターを作る場合（玄人向け）生成時にインタラクティブにパラメーターを調整できる ○ yeoman（JavaScript製） ■ https://yeoman.io/ ○ cookiecutter（Python製 / 玄人向け） ■ https://github.com/cookiecutter/cookiecutter ● Github Template（初心者にも優しい） ○ https://help.github.com/ja/articles/creating-a-repository-from-a-te mplate テンプレートジェネレーター自由度が高いタイプ 17 情報収集の巡回と消化に必要な知識 - 環境構築をする

Slide 18

Slide 18 text

● メンテナンス頻度 ○ 主にpackage.jsonのdependenciesを見るとよい ○ GitHubを見れば最終更新日があるので、それを観察 ● 公式が出しているものほどメンテナンスされている ○ スターが付いていても老朽化しているものが多いので注意テンプレートジェネレーターを使うときに気をつけること 18 情報収集の巡回と消化に必要な知識 - 環境構築をする

Slide 19

Slide 19 text

テンプレートジェネレーターを使ったほうが良いか？（個人的意見） ● 環境構築に興味が湧くまでジェネレーターを使うほうがモチベーションが保てるため。 ● 寄り道をすると多くの知識は得られるが、知識の点を線でつなげるのはとても時間がかかるため。 19 情報収集の巡回と消化に必要な知識 - 環境構築をする

Slide 20

Slide 20 text

“ ネットワーク環境が良ければジェネレーターのDEMO 20

Slide 21

Slide 21 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 21 情報収集の巡回と消化に必要な知識

Slide 22

Slide 22 text

テーマを決める何もテーマが思いつかない場合は以下の2つを題材につくる ● カウントアプリ ○ Hello World気分で作る ● TODOリスト ○ 応用を利かせて作る ○ http://todomvc.com/ 迷ったらこれ 22 情報収集の巡回と消化に必要な知識 - テーマを決める

Slide 23

Slide 23 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 23 情報収集の巡回と消化に必要な知識

Slide 24

Slide 24 text

● デザインパターン ○ https://www.techscore.com/tech/DesignPattern/index.html/ ● アーキテクチャ ○ アプリケーション系 ■ ドメイン駆動開発（ユビキタス言語, DI, DIP, CQS, CQRS, ...etc ) ○ インフラ系（Backend領域） ■ Continuous Integration（CI）/ Continuous Delivery(CD) ■ Websocket / Rest API Why：小手先のテクニックだけではない話がたくさん転がっている為設計と開発の練習内容なるべく早く手を出したほうが良いもの 24 情報収集の巡回と消化に必要な知識 - 設計・開発

Slide 25

Slide 25 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 25 情報収集の巡回と消化に必要な知識

Slide 26

Slide 26 text

バグが発生してもなかなか解決しないバグの種類によって、バグの特定と対策が可能な状態を目指す ● 理解度の問題：同期・非同期処理などの理解がおいつていない ○ 例）callback, Promise, async/await ● 技術の問題：テストが無い ○ テストを自然に書ける環境がないなど ● 複雑度の問題：バグの原因が絞り込めない場合 ○ 責務分離が明確でないアーキテクチャの可能性 ○ 要件が複雑な場合（現実） 26 情報収集の巡回と消化に必要な知識 - バグ

Slide 27

Slide 27 text

バグが発生してもなかなか解決しないできる範囲で仕組みで解決する ● 理解度の問題 ○ わかるまで調べる（大前提） ○ わからなければ、Q&Aサイトにわかったところまで質問する ● 技術度の問題 ○ テスト(jest) / 構文チェック(eslint) / 型(typescript) ● 複雑度の問題 ○ アーキテクチャで受け止める（難易度高） ○ ドキュメントで情報共有など → 後のスライドで掘り下げる 27 情報収集の巡回と消化に必要な知識 - バグ

Slide 28

Slide 28 text

アプリケーション開発の練習をするとき開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 28 情報収集の巡回と消化に必要な知識

Slide 29

Slide 29 text

WEBフロントエンドの場合、HTLM/JavaScript/CSSをWEBサーバーにアップロードすれば完了します。代表的な例は以下。 ● GitHub Pages（https://pages.github.com） ● Netlify（https://www.netlify.com）初めてやる場合や、検証用、コストを掛けたくない場合におすすめデプロイする最も簡単な方法 29 情報収集の巡回と消化に必要な知識 - デプロイ

Slide 30

Slide 30 text

デプロイするもっといろいろ試しておきたい人向け自分でWEBサーバーを立ち上げたい場合 ● Nginx / Apacheなどを利用 ○ GCP/AWS/さくら/ロリポップなどでホスティング ○ Ansibleなどの構成管理ツールを使ってみる ● コンテナでデプロイ ○ Docker Swarm / k8s ○ オーケストレーションツールの練習など ● CDNにデプロイ ○ AWS / GCP / Fastlyなど 30 情報収集の巡回と消化に必要な知識 - デプロイ

Slide 31

Slide 31 text

まとめ ● 手を動かすまでが短くなるように、ツールを使って楽をすること。 ● モチベーション低下を避けるために、相談相手がいない場合や十分な時間が取れない場合とき、環境構築などの技術的難易度の高いところは後回しにしておく。 31

Slide 32

Slide 32 text

“ 小休止質問など 32

Slide 33

Slide 33 text

検索をかけたときになぜこれを使っているのか？何が良いのか？どこへ向かっているのか？を解消したい。 33 WEBフロントエンドの背景知識（ざっくり版）

Slide 34

Slide 34 text

34 jQueryと仮想DOM ● jQueryはスクレイピング ○ レンダリングされた目的の DOMを取得し、イベント(onClickなど)をバインドする ■ 目的のDOMがレンダリングされていると限らない ■ DOMの取得 → バインド → 要素の更新 → バインド, etc… を実装すると小規模を超えたあたりからコードが瓦解を始める ● 仮想DOM ○ JavaScript内からDOMを生成する。 ■ → DOMがあることを保証できる ○ 生成時にイベント(onClickなど)をバインドする。 ○ JavaScript内でDOMのライフサイクルを定義できる → JavaScript内でDOMのライフサイクルを手に入れた

Slide 35

Slide 35 text

DOM？ライフサイクル？ ● DOM（Document Object Model） ○ 値（文字列/数値）、スタイルの両方を持つ ● DOMのライフサイクル（ざっくり） ○ DOMは受け取るイベントから、表示を変化させる 35 生成表示イベント更新

Slide 36

Slide 36 text

ライフサイクルをJavaScriptで管理すると何が良いのか？① ● アプリケーションに必要なデータの流れと、ユーザーに提供するViewの管理を分離することができる。右図の例の場合 ● アプリケーションに必要なデータ ○ 氏名の値「hoge fuga」 ○ 年齢の値「18」 ● 上記以外はViewを構成する情報 ○ フォーム/氏名/年齢 ○ 枠、サイズなど 36 hoge fuga 18 氏名年齢フォーム

Slide 37

Slide 37 text

ライフサイクルをJavaScriptで管理すると何が良いのか？② ※ここから先はデータと呼ばず、状態（ State）と呼びます。 ● フロントエンドが扱う状態のことを Stateと呼ぶことが多い。状態（State）をDOMから引き剥がして、JavaScriptの中で取り扱うことができたので、一般に知られているアーキテクチャを用いた状態管理を行うことができるようになった。 → 次のページに具体例 37

Slide 38

Slide 38 text

アーキテクチャで対応すること例：仕様変更 ● 氏名、年齢を入力と同時にフォーム下部に「〇〇さん〇〇歳」と表示するようにする。 38 hoge fuga 18 氏名年齢フォーム hoge fugaさん 18歳 const state = { name: “hoge fuga”, age: 18 }; Stateの参照をそれぞれの DOM に渡すだけで済む

Slide 39

Slide 39 text

“ 39 時間があれば仕様変更をカウントアプリでDEMO

Slide 40

Slide 40 text

アーキテクチャがもたらすもの 40 ● 一定の水準を満たした品質をアプリケーションを構築できる。 ● ライブラリやフレームワークは非機能要件の多くを最初から提供してくれている。 ○ 例えば今回取り上げたデータの整流機能を予め持っているなど

Slide 41

Slide 41 text

より品質を上げるための方法 ● 実際の成長するアプリケーションは、ライブラリやフレームワークが提供するアーキテクチャでは対応しきれない点が生じる。 ● ドメイン（=ソフトウェウア化する対象）に対して深い理解をし、特定の技術に依存しない設計が必要となってくる。 ○ → ドメイン駆動開発へつながる ● 洗練されたアーキテクチャは誰が書いても、実装方法や実装場所が同じ様になってくる。 41

Slide 42

Slide 42 text

● React/Vueなどのフレームワークは DOMのライフサイクルをJavaScript中に収めた。 ● フレームワークは一定の水準を満たした品質を提供する ● ただし、開発的な骨格という位置づけ。 ● 仕様変更や新機能実装などの実際の要件に対応するにはドメインを含む設計を行う必要がある。まとめ 42

Slide 43

Slide 43 text

全体のまとめ ● 筆者のキャッチアップ方法について紹介した ● フロントエンドの学習で躓きそうなポイントについて問題とその解決方法を紹介した ● WEBフロントエンドでメジャーなライブラリらが行っていることについてエッセンスを話した 43

Slide 44

Slide 44 text

“ 44 おわり