結果
ブログ
目標：月 8 回（週2回）更新
結果：月 10 回 更新
読書
目標：月 1 冊
結果：月 3 冊
反省点など
満遍なくインプットできました。
来月に向けて
AWS資格と並行しつつフロントエンド領域もとなると難しいですがなんとかやっていきたいです。
【読書メモ】ポケットスタディ AWS認定 デベロッパーアソシエイト
ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ)
- 作者:山下光洋
- 発売日: 2021/03/09
- メディア: 単行本
DOP資格対策として、今月発売のDVA対策本を読みました。
目次
- SECTION1 AWS認定デベロッパーアソシエイト
- SECTION2 展開（デプロイ）
- SECTION3 セキュリティ
- SECTION5 リファクタリング
- SECTION6 モニタリングとトラブルシューティング
- SECTION7 本試験想定問題集
SECTION1は試験概要。
SECTION2〜6が各カテゴリーに準じたサービスや機能の解説+章末のサンプル問題。
SECTION7は50問の問題集です。
ボリュームとしてはかなり豊富で細かく各サービスの機能やAPIまで網羅されている印象です。
章末のサンプル問題（復習用の問題）も数が豊富で、各章読み込まないと答えられないものになっているので基礎知識の習得に向いていると感じます。
良かった点
- DVA試験に必要と思われるサービスや解説が網羅されている
- 章末のサンプル問題で解説されていた知識の定着ができる
- 重要な機能説明には設定・構築手順がマネジメントコンソールのキャプチャ付きで解説されている
- API名、メトリクス名、ポリシー、コードなど細かく記載されている
悪かった点
- ポケットスタディシリーズ共通かもしれませんが、見出しが分かりづらい
- キャプチャの一部が低解像度になっている
感想
網羅範囲としては値段に相反してかなり広くボリュームも多く感じました。
DVA→SAPの順で受験済みですが、SAPの際に知った移行の6つのRなども掲載されているので、むしろDVAの範囲にとどまっていない印象です。
試験対策本ですが、開発系サービスの基礎知識の向上や概要を知りたいためのリファレンスにも使えるのではないかと思います。
今回に限らずですが、AWSでできることが多すぎる分どこまで勉強しても果てしないな..という感想。
設定手順がキャプチャ付きで掲載されているので、CloudWatchエージェントはSystems Managerでインストールするんだなど新しい発見も多々ありました。
特にアーキテクト試験の設計系とデベロッパー試験の開発系で扱う範囲や覚えることの粒度みたいなものも変わるので、その頭の切り替えにはとても良い本でした。
Nuxt.js + AWS ECS Fargate その4（まとめ）
GitHub
https://github.com/yuheijotaki/nuxt-fargate_app
これまでの記事
構成
- Nuxt.js（SSR）のコードを GitHub にプッシュするとCodePipelineが走る。
- CodeBuild でイメージをビルド。ECRへイメージを登録
- CodeBuild の成功を受けてタスク・サービスの更新。
- ECS（Fargate）が ECR からイメージ取得。
- CodeDeploy が ECS（Fargate）へデプロイ。
VPC内はコンテナタスクを各サブネットに配置しALBで分散する。
感想
当初AWSサービスを使ってアプリを公開するところまでしてみたいなという気持ちから、 Nuxt.js + Ruby on Rails + AWS Fargate の開発・デプロイチュートリアル を本の内容通りに構築することを検討していました。
ただ最初のRubyのDB設定のところでつまづきまくり、バックエンド構築を理解したいわけでもないしなぁ..と考え直し、今回の Nuxt.js + ECS + CodePipeline という構成でやってみる形になりました。
大枠の感想としては、資格勉強はあまり役には立っていないかもなというのという気持ち半分、意外と何日か触れば一通りはできるものだなという気持ち半分と言った所です。
実際には考慮するべき点が多くあると思っています。
- サービスのスケール面
- ALBのターゲットグループの設定内容
- DockerのCPU,メモリ等の設定内容
- アプリケーション設定
- DNS設定
- nuxt.config.js
- ビルド&デプロイ設定
- テスト
- ステージングや本番環境などステージごとのデプロイ
- セキュリティ
- ググりながらやってみたものの、特にタスク定義ロールなどの理解が乏しい
このようなことをやってみると、インフラエンジニアや開発エンジニアの方はこれらの考慮点なども含め構築されていると思うので、改めてすごいなということでした。
特にCodeDeployの権限周りをかなりググりながら進めましたが、AWSのドキュメントで日本語訳が追いついていないものやエラー内容が引っかからないなどあり検索能力や基礎知識が足りていないなと実感もしました。
ただほんわりとしか分かっていなかったコンテナというそのものであったり、CodePipelineの設定などを実際にやってみて、多少は理解は進んだという感触もあるので次回また何かしらに生かしていきたいと思います。
Nuxt.js + AWS ECS Fargate その3（CI/CD環境作成）
前回に続いてAWSのCodePipelineを使用してCI/CD環境を作成しようと思います。
アプリケーションコードのリポジトリはGitHubを使用しているので、GitHub Actionsでもできるようですが、そちらは一度触ったことがありAWSサービスの理解を深めたいので今回はAWSサービスを使用してみます。
ECS → CodeDeploy だけでECRリポジトリにプッシュされた際にデプロイ実行をできますが、CodePipeline を使って少し実戦的にやってみました。
参考にしたのは下記の記事などです。
- AWS CodePipelineを使用してgit pushでAmazon ECSをデプロイする | SEEDS Creators' Blog | 株式会社シーズ
- Aws Code PipelineでReactjs/Nextのデプロイを自動化！ECSへ展開してみました | Ragate ブログ
- ECSのCI/CD環境をCodePipelineに変えた話 | 株式会社CAM
- 【AWS】GithubからCodePipelineでECS/Fargateにデプロイする方法 - Qiita
- 【備忘録】AWS ECS Blue / Green Deploy 実現のために学んだこと - Qiita
- AWS_CICD_ECS_Handson.pdf
パイプラインを作成
ECS > クラスター > 該当のサービスを選択 > 「デプロイメント」タブ > パイプラインを作成
# Step1 パイプラインの設定を選択する パイプライン名: nuxt-fargate-pipeline サービスロール: 新しいサービスロール ロール名: AWSCodePipelineServiceRole-ap-northeast-1-nuxt-fargate-pipeline # Step2 ソースステージを追加する ソースプロバイダー: GitHub（バージョン2） 接続 → 接続名: 任意のもの リポジトリ: 該当リポジトリ ブランチ名: master ソースコードの変更時にパイプラインを開始する: チェック # Step3 ビルドステージを追加する プロバイダーを構築する: AWS CodeBuild リージョン: アジアパシフィック（東京） ## ビルドプロジェクト プロジェクト名: nuxt-fargate-build オペレーティングシステム: Amazon Linux ランタイム: Standard イメージ: 最新のもの イメージのバージョン: 最新のもの 環境タイプ: Linux Docker権限付与: チェック サービスロール: 新しいサービスロール ロール名: codebuild-nuxt-fargate-build-service-role ## 環境変数 AWS_ACCOUNT_ID: <アカウントID> AWS_DEFAULT_REGION: ap-northeast-1 REPOSITORY_NAME: nuxt-fargate_app REPOSITORY_URI: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com IMAGE_TAG: latest # Step4 デプロイステージを追加する デプロイプロバイダー: Amazon ECS（ブルー/グリーン） リージョン: アジアパシフィック（東京） 入力アーティファクト: BuildArtifact AWS CodeDeploy アプリケーション名: nuxt-fargate-deploy AWS CodeDeploy デプロイグループ: nuxt-fargate-deploy-group Amazon ECS タスク定義: BuildArtifact AWS CodeDeploy AppSpec ファイル: BuildArtifact 入力アーティファクトを持つイメージの詳細: BuildArtifact タスク定義のプレースホルダー文字: IMAGE1_NAME
サービスロールの設定
ECRにアクセスできるようにCodeBuildのサービスロールを設定する。
CodeBuild > ビルドプロジェクト > 該当のプロジェクト > 「ビルドの詳細」タブ > 環境 > サービスロール
のARNをクリックし、 AmazonEC2ContainerRegistryPowerUser ポリシーをアタッチする。
参考： 【備忘録】CodeBuildでaws ecr get-loginコマンド実行時にエラーが発生する - Qiita
設定ファイルの準備
- buildspec.yml: ビルド設定ファイル
- appspec.yaml: ECSサービスに含めるタスク定義の設定ファイル
- task-definition.json: デプロイするタスク定義の設定ファイル
ビルドしてみて、エラー参考にググってみたいにしてなんとかビルド成功しました。
雰囲気はGitHub ActionsやNetlifyと同じですが、コンソール内の権限周りが悪いのか、コードの記述が分からなくてハマってしまいました。
10回もしないうちにDockerのRate Limitに引っかかったので、下記の対策を行うなどを推奨します。
参考： Docker Hub の Rate Limitに引っかかったのでdocker loginで対策した - fu3ak1's tech days
確認
以上の手順でパイプライン作成。
masterにプッシュしたら、ECRリポジトリにプッシュされ、ビルドしたイメージがALBにデプロイされる。
次回はこれまでのまとめを兼ねて構成図等で振り返りをして終わりにしようと思います。
Nuxt.js + AWS ECS Fargate その2（ALBとECS Fargate展開）
前回に引き続きAWS側の設定を行っていきます。
コンテナのタスク、サービスについては改めて理解するため下記が参考になりました。
基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環境構築 #Fargate | DevelopersIO
構築手順の参考にした記事は Amazon Fargate でコンテナを動かす - Qiita になります。
ALB の構築
Application Load Balancer を作成。
関係ないですが、ALBがEC2のメニューの中にあること、Gateway Load Balancer という新しい種類のロードバランサーがあるのを初めて知りました。
# ロードバランサーの設定 名前: nuxt-fargate-load-balancer スキーム: インターネット向け リスナー: HTTP:80 VPC: デフォルトVPC AZ: ap-northeast-1a, ap-northeast-1c のサブネット # セキュリティグループの設定 セキュリティグループ名: nuxt-fargate-sg タイプ: カスタムTCP プロトコル: TCP ポート範囲: 80 ソース: カスタム 0.0.0.0/0, ::/0 # ルーティングの設定 ターゲットグループの名前: nuxt-fargate-target-group ターゲットの種類: IP プロトコル: HTTP ポート: 80
ECS Fargate設定
タスク → クラスター → サービスの順で作成。
認定試験勉強でもごっちゃになるやつですが、クラメソさんの下記の説明が個人的には一番しっくりきます。
- ECS クラスタ → 以下のサービスとタスクの器、かたまり
- ECS サービス → タスク（以下）を指定し、何個起動するのか指定、ALBと関連付けするもの
- ECS タスク → CPU/メモリの割り当て、ポート設定などDockerコンテナの起動方法を指定する設定書みたいなもの
タスク実行ロールを作成（ない場合）
事前にロール ecsTaskExecutionRole がない場合は作成しておく。
※ Amazon ECS タスク実行 IAM ロール の「タスク実行 IAM ロールの作成」通りに作成する。
タスク定義の作成
ECS > タスク定義 > 新しいタスク定義の作成 > FARGATE を選択
# タスクとコンテナの定義の設定 タスク定義名: nuxt-fargate-task タスクロール: ecsTaskExecutionRole タスクメモリ (GB): 0.5GB タスク CPU (vCPU): 0.25vCPU ## コンテナの追加 コンテナ名: nuxt-fargate-container イメージ: <イメージURI> ポートマッピング: 80
イメージURIはECRのイメージURI ***.dkr.ecr.ap-northeast-1.amazonaws.com/*** を入力
クラスターの作成
ECS > クラスター > クラスターの作成 > FARGATE を選択
# クラスターの設定 クラスター名: nuxt-fargate-cluster
サービスの作成
ECS > クラスター > 「サービス」タブ > 作成
# サービスの設定 起動タイプ: FARGATE タスク定義: nuxt-fargate-task クラスター: nuxt-fargate-cluster サービス名: nuxt-fargate-service タスクの数: 2 最小ヘルス率: 50 最大率: 200 # ネットワーク構成 クラスター VPC: デフォルトVPC サブネット: ap-northeast-1a, ap-northeast-1c ロードバランサーの種類: ALB ロードバランサー名: nuxt-fargate-load-balancer ## ロードバランス用のコンテナ プロダクションリスナーポート: 80:HTTP ターゲットグループ名: nuxt-fargate-target-group
確認
EC2 > ロードバランサー > 該当のELB選択 > DNS名
http://nuxt-fargate-load-balancer-*******.ap-northeast-1.elb.amazonaws.com/ にアクセスするとサイトが無事表示されました。
表示されない場合は、
- ECS > クラスター > タスク > ステータスが
RUNNINGになっている - EC2 > ターゲットグループ > 該当のターゲットグループ選択 > Targets > Statsが
healthyになっている
かを確認して unhealthy などになっていればトラブルシューティングを行う。
最初、ALBのターゲットの種類をインスタンスで設定してしまい、unhealthy でサイトも表示されないままになってしまいました。
ALBの作成、ECSの設定を再度Qiitaの記事参考にやり直して2回目で無事表示できました。
VPCやセキュリティグループも触るの試験勉強のハンズオン以来でしたが、とりあえず表示させる所までできてよかったです。
Nuxt.js + AWS ECS Fargate その1（Nuxt.jsアプリ作成〜ECRリポジトリへのプッシュ）
トレンドのVuejs/NuxtをAws ECS, FargateでSSR、詳細解説します🚀 の記事を参考に進めてみる。
ローカル環境 使用バージョン
Nuxt.js アプリの作成
create nuxt-app で作成します。
$ yarn create nuxt-app nuxt-fargate_app yarn create v1.13.0 create-nuxt-app v3.6.0 ...
設定項目は下記のようにしました。
Fargateで動かすのでRendering modeはUniversalを指定。
しばらく触ってないと細々変わりますね。。
? Project name: nuxt-fargate_app ? Programming language: JavaScript ? Package manager: Npm ? UI framework: None ? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Linting tools: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Testing framework: None ? Rendering mode: Universal (SSR / SSG) ? Deployment target: Server (Node.js hosting) ? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? What is your GitHub username? yuhei jotaki ? Version control system: Git
Dockerfile を使用してイメージを作成
Docker 向けに package.json の scripts を調整する。
... "scripts": { "dev": "HOST=0.0.0.0 PORT=3000 nuxt", "build": "nuxt build", "start": "HOST=0.0.0.0 PORT=3000 nuxt start", "generate": "nuxt generate" }, ...
Dockerfile をプロジェクトディレクトリに作成して下記のようにする。
Node.jsのバージョンは 公式のイメージ を参考にする。
FROM node:12 RUN mkdir -p /var/www/nuxt-fargate_app WORKDIR /var/www/nuxt-fargate_app COPY ./ /var/www/nuxt-fargate_app RUN npm run build EXPOSE 3000 ENTRYPOINT ["npm", "run", "start"]
次にDockerアプリをrunningにする。
その後ビルドしてイメージが作成できているか確認。
$ docker build -t nuxt-fargate_app . ... Successfully tagged nuxt-fargate_app:latest
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nuxt-fargate_app latest XXXXX 39 seconds ago 1.03GB ...
起動してみる。
ここはあまり分かってないですが、 0.0.0.0:3000 でアクセスできたのでOKなのかな
$ docker run -d -p 3000:3000 nuxt-fargate_app ... $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61f86de41a7a nuxt-fargate_app "npm run start" 21 seconds ago Up 19 seconds 0.0.0.0:3000->3000/tcp amazing_yalow
ECRでリポジトリを作成してイメージをプッシュする
AWS ECR > リポジトリ作成をする。
今回は nuxt-fargate_app というリポジトリ名にしました。
その後コマンドで認証してイメージをプッシュする。
それぞれつまづきましたが、認証は get-login は現在非推奨のため get-login-password が良いとのことで Amazon ECR での AWS CLI の使用 - Amazon ECR を参考にしました。
※ 後々振り返ると、ECRコンソール内 > リポジトリ > 該当リポジトリを選択 > プッシュコマンドの表示 にもコマンドが書いてありました。
# <profile-name>: ~/.aws/credentials のプロファイルの名前 # <app-name>: nuxt-fargate_app # <aws-region-name>: ap-northeast-1 # <aws-account-id>: アカウントID # ユーザー切り替え $ export AWS_DEFAULT_PROFILE=<profile-name> # 認証トークンを取得し、レジストリに対して Docker クライアントを認証します。 $ aws ecr get-login-password | docker login --username AWS --password-stdin https://<aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com # Docker イメージを構築します。 $ docker build -t <app-name>:latest . # 構築が完了したら、このリポジトリにイメージをプッシュできるように、イメージにタグを付けます。 $ docker tag <app-name>:latest <aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com/<app-name>:latest # 新しく作成した AWS リポジトリにこのイメージをプッシュします。 $ docker push <aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com/<app-name>:latest
以上でイメージをプッシュできました。
AWSのコンソールやCLI最近あまり触る機会がなかったですが、CLIのバージョンアップやプロファイルの切り替え等々つまづくところが多かったです。
正直あまり分かってない部分も多いですが、次回以降はECSの設定になりそうですので引き続き更新できたらと思います。
【読書メモ】フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装
目次
- Part1 導入編 なぜ使うかを知る
- Chapter1 フロントエンドエンジニアの歴史
- Chapter2 フロントエンドエンジニアに求められるスキル
- Chapter3 フロントエンドにおける一般的なツール群
- Chapter4 開発の現場における仕事の進め方
- Part2 実践編 どう使うかを学ぶ
- Chapter5 開発環境
- Chapter6 設計と実装
- Chapter7 CI/CD によって受けられるメリット
- Part3 応用編 より深く学ぶために知る
- Chapter8 解析とモニタリング
- Chapter9 チーム開発と Web への貢献
Part1ではフロントエンド領域においてツールの紹介を取り入れつつ、そのツールを使う意義を解説しています。
Part2ではシンプルなjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材に、環境構築・設計/実装・テスト・CI/CDの構築までのより実践的な内容の説明です。
最後のPart3ではプロダクトにを伸長させるためのGoogle AnalyticsなどSaas解析ツールの活用、実際にチームで働くことをイメージしやすいようにスクラム開発の現場でどのような役割をフロントエンド領域において行うかなどが解説されています。
著者のおひとり武田さんのブログ 「フロントエンド開発入門」出版のお知らせ でも触れられていますが、「これが今のフロントエンドの主流の技術スタックです」というような紹介や解説本ではなく
- 昨今の移り変わりが早いフロントエンドという領域とどのように向き合うべきか
- そのために必要となるスキルはどのようなものがあるか
- なぜ現在主流のツール、フレームワークが求められているか
を主にフォーカスした内容となっていました。
ポイント
Part1 導入編 なぜ使うかを知る
Chapter1 フロントエンドエンジニアの歴史
ティム・バーナーズ＝リー的なところから90〜00年代のブラウザ戦争、ブログ流行などの流れから当時のマークアップエンジニアやHTMLコーダーという職種がどのように関わりを持ち始めたかという内容。
その後のJavaScriptを用いて動的なUIを提供する流れを経て2000年代後半から「フロントエンドエンジニア」という専門職が一般化し始める。
個人的には、2010年前後からHTML/CSS/JS（jQuery）を触ったりしていて、書かれているようなAngularJS、Backbone.jsなどSPAを実現するためのフレームワークの存在はちらっと横目で見てる程度でした。
HTMLのマークアップ、CSSによるスタイリングという範疇に収まらない、より一層専門性の高い能力が求められると「フロントエンドエンジニア」という言葉がここでようやく専門職として一般化しだします。 それと同時にサーバサイドのWebエンジニアがフロントエンドに軸足を置いたり、デザイナーがマークアップを簡単なUI実装まで担当したりとフロントエンド界隈は徐々にボーダレス・るつぼ化してきます。
ちょうどこのときですね。自分はデザインから入ったので「デザイナーがマークアップを簡単なUI実装まで担当したり」に近いところでこの仕事に足を踏み入れたと思っています。
その後Node.jsが発表、npmによって開発におけるエコシステムが急速に充実。ライブラリのバージョン管理やタスクの自動化が可能になる。
同時にECMAScriptへ追加仕様提案の動きが活発化。次期バージョンES6への利用熱が高まりES6からES5への変換ツール、6to5（後のBabel）が発表され注目され始める。
一方でトレンドが日々移り変わるかのような世界になってしまい、海外を中心に JavaScript/Front-End Fatigue（＝フロントエンド疲れ）といった言葉が囁かれるようにもなる。
- HTML/CSS/JavaScriptの仕様のアップデート速度
- 支払いや認証APIをChrome（ブラウザ）が提供し、OSやデバイスと紐づく仕様提案が増加
- プライバシー保護の動きやセキュリティ上の懸念（.userAgent文字列の凍結予定など）
確かに Angular/React/Vue 以外にも当時JSフレームワークは当時雑多にあって絞れない状態だったりしたので、日本でもフロントエンドの領域広すぎ問題はあがっていた記憶があります。
このような経緯などがあるなかで、この書籍ではすべての情報をキャッチアップし網羅するのは難しいため、
- 昨今の技術要素が何のために必要なのか、何を解決するのか
- 実践的な内容で技術要素を取り扱い必要なことを必要なタイミングで学ぶ
ことにフォーカスした内容を以降で取り上げています。
Chapter2 フロントエンドエンジニアに求められるスキル
フロントエンドエンジニアでは実務でどのようなスキルが求められるかについて解説されています。
想定される実務例
- 意味付けと文書構造・アウトラインが情報として適切に設計されたHTMLマークアップ
- デザイナーと連携し画面に必要なパーツの書き出し依頼を行う
- 保守性を重要視したCSSの設計およびスタイリング
- WordPressに代表されるようなCMSの構築、テンプレート実装と運用ができる
- 任意のJavaScriptフレームワークを十分に理解し実装する
- Node.jsと周辺のエコシステムを理解したビルドパイプラインを実装する
- Atomic Designによるコンポーネント設計を中心に据えFigmaでデザインしJSXとCSS in JSを利用し実装する
- コンバージョンレート向上目的のA/Bテストの設計と結果から得られる簡単な分析とUI改善施策の提案
- SEOのためにmeta要素を最適化、SNSでの参照時にOGイメージを表示させる
- 画面キャッシュやアセットファイルのライフサイクルを考慮したCDNキャッシュ戦略とデプロイにおけるインフラ担当との協働
- React SSRを目的としたExpressの実装
- 既存REST APIをバックエンドとしたフロントエンドに親和性のあるGraphQL APIサーバの実装
- QA部門のテストエンジニアと協働し仕様から正常系のテスト項目のレビューを行う
フロントエンドエンジニアの実務から想起されるスキル群
羅列するととんでもない広さに見えてしまいますが、あくまでも必要なスキルを整理するための一覧。
この中でネックに感じることが多い部分はJavaScript周辺の情報のキャッチアップなどが多いように感じるとのこと。
現代においては「フロントエンド = JavaScriptのスキルセットが必須である」というイメージが拭いきれないと感じています。同時にフロントエンドエンジニアであると自認する開発者が必ずしもCSSやデザインについて十分な知識があるとは言いにくいのも現状です。
この点は、The Great Divide | CSS-Tricks という記事でも現在の「フロントエンドエンジニア」という言葉の意味が二分されており、その隔たりはかなり大きなものであると主張しています。
関心や責務の中心がJavaScriptによって解決できることを守備範囲としている開発者と、HTML・CSS・デザインやインタラクション・アクセシビリティにスキルセットが集中した開発者では活躍できるフィールドが大きく異なります。この主張に同調する意見も多かったことから、フロントエンドという言葉に求められる要素の多様化を示唆していることは紛れもありません。昨今では前者をフロントエンドソフトウェアエンジニア・フロントエンドWebデベロッパーとし後者をUXエンジニアとすることで区別し、まったく別のキャリアが用意されていることもあります。
とのことで、網羅すべき範囲が広くなってきたフロントエンドに対する理解や、二分されたイメージを開発チームがまだ持っていないという状況にある場合、まずはチームに必要なスキルセットが何であるかを明確にし、分野が違いすぎていないかを考える必要がありそうです。
やみくもに特定のスキルセットに対してベッドするということは、開発者としてあまり賢い成長戦略ではないように思えるということです。
「The Great Divide | CSS-Tricks」より引用
今もWebの成長は止まらず今後も加速するであろうなかでどうしたらいいのか、というと
必要なとき（求められたときに）、正しい場所から、必要な情報を、深く調べて身につける
何か課題を目の前にした際、いつでも実現できる状態にしておくということはフロントエンドエンジニアとして健全であるとのことで、難しそうだな。。とも思いつつ確かに負荷のかからない付き合い方としては適当なんだろうなと感じました。
最後に本書におけるフロントエンドエンジニア像として、
- 本格的なプロダクト開発チームへの参画は初めてとなる
- ブラウザを主戦場としWebをプラットフォームにしたアプリケーション開発への興味関心がある
- JavaScriptに関連する情報へのアンテナ感度が高い
- デザインのオーサリングツールについては扱ったことがない
- セマンティックなHTML構造への理解はあるものの熟知しているわけではない
- CSSによるフルスクラッチのスタイリングや特定のCSS設計手法についての知識は乏しい
としています。つまり、The Great Divide の区分でいうと「フロントエンドソフトウェアエンジニア・フロントエンドWebデベロッパー」に近いフィールドを担う人というイメージをしました。
Chapter3 フロントエンドにおける一般的なツール群
ここでは具体的なライブラリやツールの紹介になります。またそれらが開発においてどういった課題を解決するのかといった観点が下敷きとして記載されています。
Node.jsとその周辺のエコシステム
- 非同期型のイベント駆動モデルを採用したサーバーサイド向けのJavaScript
- npm,Yarnなどのパッケージマネージャー
- フロントエンドの開発環境構築を支える根幹そのもの
- BFF（Backends For Frontends）層とブラウザとで同じ言語であるJavaScriptを扱うことも可能
- フロントエンドを発端として発展したJavaScriptの価値のある言語の発展にはNode.jsがある
コンパイラ・モジュールバンドラー
- Babel,webpack など
- 言語仕様を吸収し解釈可能な状態で展開・連結する変換器
- Babel：下位構文へダウンコンパイルする役割。ECMAScriptの年次策定する新しい仕様決定に対応可能
- webpack：言語仕様の一部であるモジュール機構を実装していない下位環境においてのエミュレートを担当。他にParcelやRollup.js
- 開発において変更可用性、スケーリングの担保をもたらす恩恵となる
JavaScript代替言語：TypeScript
- JavaScriptに類似した言語体系を持ちつつ別の特性によって開発者に違った体験を与える、最終的にはJavaScriptにコンパイルされる言語
- 静的型付言語であり型チェックとJavaScriptへのコンパイルも担う
- コンパイラとしての一面も
- スクリプト実行前の未然検知が可能、型補完やエラー発見を向上などの恩恵
フレームワーク：ビューライブラリ：Vue.js,Angular,React
- Vue.js：モノリシックなフレームワークと異なり、少しづつ適用可能
- Angular：HTMLとTypeScriptでSPAを開発するフレームワーク。ファイル構成やソフトウェアパターンなど初手から学習領域が多い
- React：UI構築のためのライブラリ。オールインワンではなくUI表現のみに関心を寄せる
- いずれもコンポーネント指向のフレームワーク・ライブラリ。変更が容易で、すぐに代替可能であるといった「捨てやすさ」が大きな特長
その他
- 状態管理のライブラリやパターン MVCの説明、Redux,Fluxの例
- コンポーネント管理の煩雑さを少なくするため
- CSSメタ言語、CSS-in-JS
- 長期的な保守・運用のため
- 静的解析ツール：Prettier,ESLint
- 機械的にコードスタイルを規定するため
- ユニットテスト：Mocha,Jest,Karma
- 変更可用性に耐えうる環境を作るため
Chapter4 開発の現場における仕事の進め方
主にアジャイル、スクラムの開発手法とフロントエンドエンジニアがどのように関わるかの解説。
ゴールに向かって進み続けるプロダクトにおいて、変更要求を受けやすいのがフロントエンド・クライアントサイドでもあるのです。つまり、ユーザーや利用者に価値を届けるために一番近いエンジニアリングのフィールドにいるのがフロントエンドエンジニアと言ってもよいでしょう。
と他のサーバーサイドエンジニアとの違いが述べられています。
また一般的な開発チームの職種の紹介、そのなかでの役割については開発を前に進めるコミュニケーションハブのような責務も持つこともあるということです。
開発において最新のライブラリやフレームワークや技術要素を選択することは優先度の高い事項ではありません。動くプロダクト＝アプリケーションを速いサイクルで変化に対応しながらユーザーに届けるために、必要な解決策を持っていることが重要です。
デザイナーともサーバーサイドともPM・ディレクター的な立ち位置の人とまんべんなく絡んでいくので、コードを書くという部分のみのテクニカルスキルだけでなく、他の頭を使ったりコミュニケーションスキルも必要ってことですね。
Part2 実践編 どう使うかを学ぶ
書籍のレビューサイトのjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材にしてコードを交えながら解説しています。
- Yarn,Docker,webpackを使った環境の構築
- jQueryからReact.js/TypeScriptリプレイス作業
- Jestでのテスト
- GitHub Actionsを用いたCI/CD環境構築
- Lighthouseを用いたパフォーマンス測定・改善
Part3 応用編 より深く学ぶために知る
Chapter8の解析とモニタリングでは、仮説検証やA/Bテストをプロダクトやサービスを成長させるフェーズでなぜ大事になるのかが解説されています。
Chapter9 チーム開発と Web への貢献
スクラム開発においてフロントエンドエンジニアがチームに効果をもたらす・メリットが得られると筆者は考えています。
- 短いリリースサイクルを実現しユーザーに価値を提供し続けます
- スプリント内には決まったイベントを定義することでチームの学習を促進しメンバーが自主的に改善を試みます
- チームやプロダクトが予期せぬ変化や不確実性の高い開発を求められる場合それに耐えうるように設計されています
技術的なトレンドのキャッチアップのためには、膨大な1次情報（WHATWGの規格など）のアップデートを追うのはほぼ不可能なので、ライトにキャッチアップすることをおすすめしています。
何らか知る必要があるか分からないという場合、まずは知るきっかけを作っておく、いったんは情報を目に入れておくということが良さそうです。
感想
Part1を中心に感想等を書きましたが、久しぶりにフロントエンド周りの本でコードが大量に掲載されているような技術書ではない類のものを読みました。
主に入門者向きの内容で、あくまでなぜそれが必要かどういう観点で使うかが主目的のためコードに関して簡易なもので記載されています。
Part2以降は実践編〜応用編になるので開発者の方は読む内容になると思いますが、Part1の最初の方に関しては非エンジニアでエンジニアの考えを知りたいみたいな興味がある方にはとても良い内容だと感じました。
実際にフロントエンドエンジニアと働いている自分からすると、なかなか客観的にフロントエンド領域というものを捉える機会がなかったのでその点が特に勉強になりました。
書籍の最後で下記のように締められていました。
昨今フロントエンドは移り変わりが早いと言われてきました。これからあなたがどのくらいフロントエンドという領域と向き合うかはわかりませんが、Webプラットフォームの仕様に影響を受けるブラウザが主戦場だからこそ変化のスピードも早いように感じることもあるでしょう。早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。新しい仕様を知ることや新しいライブラリを使うことはいずれも単体ではなんの価値も生んでいません。Webプラットフォームのエンドユーザーは開発者ではなくあなたが担当するアプリケーションのユーザーなのです。Webプラットフォームとエンドユーザー、開発者であるあなたの立ち位置は時間が経っても変わるものではありません。
ユーザーの課題を解決するために、ユーザーへの価値提供のためにWebプラットフォームを使って開発を進めていくのだ・課題を解決するのだ、ということに意識的であることや楽しむことがフロントエンド開発では大切なポイントなのです。
「早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。」というのが今までにない視点でいいなと思いました。
確かに広い範囲を細かく追うと破綻する気がしますし、目に止めとく程度でいいのかなと。
今までは技術を知らなければいけないと思いすぎていた面もあるのでそれも大事な点ではあると思いますが、もう少し本質的な仕事を思い出してユーザーに寄り添って仕事をしようと思えるような本でした。