駆け出しエンジニアの坂口諒です。
「自己紹介をしながら自分の技術レベルを伝えることができれば一石二鳥だ！」
ということで、自己紹介をポートフォリオとして作成しました。
ここではその過程と、困難に感じた点、ポートフォリオとしてのアピールポイントなどをまとめさせていただきたいと思います。
※ 自己紹介サイトにも本記事と同様の内容を載せております。
方法
Webサイト制作の流れは以下の通りです。
- 勉強
- デザイン
- 技術選定
- 開発
また開発工程では以下のような作業を行いました。
- 実装
- 細かい作業
- テスト
- CI/CDの設定
- ドメインの取得
- CDNの設定
- SSL化
- OGPタグ設定
以下では各工程の内容について述べたいと思います。
技術選定
技術選定の基準
技術選定の第一の基準は「広く使われていること」です。そのような技術は就職先で活用できる可能性が高く、また独学でも不明点を解決しやすいと思うからです。
技術選定の第二の基準は「処理速度が速いこと」です。処理の重いサイトはユーザにストレスをかけてしまいます。また処理速度はエンジニアの技術力と強く相関すると思うため、採用担当者の方からの評価していただけると考えました。
言語の選定
TypeScriptを採用しました。
Stackoverflowのサーベイによると、フロントエンドの言語として、TypeScriptはJavaScript, HTML/CSSに次ぐ3位の人気があり、広く使われています。処理速度に関しては、コンパイル後にJavaScriptになるため、JavaScriptと同じ速度だと考えられます。
また型チェックのあるTypeScriptを使うことで、JavaScriptを直接書くよりもバグを減らすことができます。IDEによる補完機能も充実しているため、開発体験も向上します。
処理速度の速いWebAssemblyを一部導入することも検討しました。しかしTypeScriptほど広く使われているわけではないうえ、重たい処理を行うわけではないので今回は採用しないこととしました。
フレームワークの選定
Gatsby.jsを採用しました。Gatsby.jsはReact.jsをベースとするStatic Site Generatorです。
React.jsは2022年現在、最も広く使われているユーザーインターフェース構築ライブラリです。React.jsの強みはDOMの差分のみを更新することで効率よくページをレンダリングできることであり、これは第二の要件である「処理速度が速いこと」に直結します。
さらにGatsby.jsを使うことでページを事前にコンパイルできるので、サイトの読み込み速度を向上させることができます。
処理速度に強みのあるSvelte.jsも検討したのですが、まだ広く使われている段階ではなかったので今回は採用しないこととしました。
勉強
Webサイト制作の基礎から勉強しました。信頼できるドキュメントから体系的に学ぶことを心がけました。
- Learn Design with Figma
- HTML elements reference - HTML: HyperText Markup Language | MDN
- JavaScript Guide - JavaScript | MDN
- The TypeScript Handbook
- React.js MAIN CONCEPTS
- Tutorial | Gatsby
デザイン
方針決定
他の方のポートフォリオサイトを調査しました。特にKeita Yamadaさんのサイトの名刺型のデザインは自己紹介にピッタリだと思い、採用することにしました。
また自分の個性として、自然を感じられる温かみのあるサイトを作ることを決めました。
デザイン制作
Figmaで以下のようなデザインを制作しました。
開発
実装
実装の際に心掛けていたことは、関数型コンポーネントを利用することです。クラス型コンポーネントよりも関心の分離が容易であるためです。
クラス型コンポーネントはcomponentDidMountやcomponentDidUpdateなどのライフサイクルメソッドによってコードを書く必要があります。一方、関数型コンポーネントではHooksでライフサイクルメソッドを置き換え、関心によってコードを分離することができるようになります。
また関数型コンポーネントではコードが短く書けます。メソッドをbindする必要もなく、コンストラクタも不要であるためです。
他に心掛けていたのは、CSSには積極的にコメントを残すということです。CSSでは個々のプロパティの役割が不明確になりがちなので、コメントで補足したり、似たプロパティをまとめるなどの工夫をしました。
本サイトのソースコードはGithubで公開しています。
その他の作業
Github Actions上にCI/CDパイプラインを構築しました。main, stg, devの3つのブランチを作り、以下のように運用しました。
- stgにプッシュすると「単体テスト」と「Staging環境へのデプロイ」が走る
- Staging環境で動作を確認する
- mainにプルリクエストを出し、マージすると「本番環境へのデプロイ」が走る
また以下の作業も行いました。
- ドメインの取得
- CDNの設定
- SSL化
- OGPタグ設定
困難を感じたポイント
CSSのデバッグに多くの時間をかけてしまいました。プロパティの変更などにより、思いもよらない場所に影響が出るためです。
今回の失敗をもとに、今後は以下のように改善したいと思います。
- CSSについて体系的に勉強し、バグの原因となるようなコードを書かないようにする
- 段階的に原因を特定するようにする
- まずバグの原因となったコミットを特定する
- 次にバグの原因となった行を特定する
- 次にバグの原因を特定する
またPCとスマートフォンで異なる挙動となることを知らず、バグの原因特定に多くの時間をかけてしまいました。当時は自分のコードが原因なのか、一般的に起きている現象なのかを判断できませんでした。
今後は、バグの挙動を具体的に言語化して検索することで、一般的に起きている現象かどうかを早い段階で理解できるように心掛けたいと思います。
アピールポイント
自然と温もりを感じてもらえるよう、スタイルを工夫しました。
- 緑と青を基調とした統一感のある色使い
- "優しい"スタイル
- 丸みのあるコンポーネント
- 背景に適用した
<feGaussianBlur>タグ
- 穏やかなアニメーション
- ゆっくり流れる雲
- たまに映り込む葉っぱ
- 穏やかな画面切り替え
- 穏やかな押下アニメーション (ダークモード切り替えなど)
またアクセシビリティを向上させる工夫もしました。
- Web Content Accessibility Guidelines (WCAG) 2をもとにした色選び
- ダークモードの導入
感想
改善点は多くあるものの、個人的には満足しています。自分の等身大の技術レベルが反映できていると思うためです。
また、見ていて穏やかな気持ちになれるので、気に入っています。
CSSに関する知識不足が目立ったので、これからは体系的にCSSについて勉強していきたいと考えています。
また自分のバックエンドの技術レベルも伝えられるような作品も作りたいと思います。