ポートフォリオサイト

目的

過去に開発したポートフォリオサイトを、より更新しやすいように作り直すために開発しました。自分がこれまでに開発したものを振り返りたいという思いから、半分自分のためのサイトでもあります。といいつつも、Next.jsとVercelを使ってみたいというのが実のところのモチベーションです。

技術選定理由

React・TypeScript

Sunaeを開発した際にReact&TypeScriptは書いていて面白かった
外部データとのやりとりをするため、型付けをしながら丁寧に扱いたかった
ReactはVueよりもTypeScriptとの相性が良い
今後フロントエンドの動向を追うのに、支配的なフレームワークであるReactへの理解を深めたい (他のフレームワークはすべからくReactを意識しているであろうため)

Next.js・SSG

Reactと同じくスタンダードとして受け入れられているNext.jsを触ってみたい
複数ページに渡るサイトならReactで頑張るよりもNext.jsに任せてしまった方がいい
ブログという性質から静的サイト生成(SSG)が最適。SSGをやるならフレームワークに頼りたかった

Vercel

手軽にホスティングできると話題になっていたので気になっていた
Next.jsの主な開発元と同じ会社のサービスだからNext.jsに最適化がなされている
サイトのUIがモダンで使いやすい
Netlifyは既に利用したことがあるため別のサービスに触れたかった。またAWSも今後触れる予定だった。Vercelに触れるには良い機会だと考えた

microCMS

HTML直書きだった既存のポートフォリオの反省としてCMSを活用することにした
JAMstackサイトのため、JSONでデータをやりとりできるシンプルなヘッドレスCMSを使いたかった
なかでもmicroCMSは国産であるため、情報が豊富
Notion APIの採用も考えたが、開発時点では機能が貧弱だったために見送り

Tailwind CSS

Sunaeの開発時に素晴らしい体験を得られたため。box-shadowやborder-radiusなどの細かい調整が不要で手軽だった
厳密な調整はしたくなかった。速さとシンプルさこそが重要だった
Material DesignやAnt Designで用意されているものより、ある程度独自にUIを組み立てたかった

day.js

JavaScriptは組み込みの日付操作が貧弱なため、ライブラリを活用した
day.jsの他にMoment.js,date-fnsなどが候補に上がった
Moment.jsは人気なもののメンテナンスオンリーになったため不採用
day.jsはdate-fnsに対し軽量・メソッドチェーンが使える(個人的に処理の流れが追いやすい)という点が魅力だった

工夫点・苦労した点

分かりやすくストレスのないデザイン

旧ポートフォリオでは結局流行らずじまいだったニューモーフィズムなデザインでした。長く運用することを考えると、一時の流行り(2021年現在でいうグラスモーフィズム)よりも実績のあるスタンダードなテイストが良いと考えました。角の丸みや影は要素が分かりやすく、且つしつこく感じないような付け方にしています。シンプルなサイトには冗長だと感じたため、ハンバーガーメニューのUIは避けました。代わりにページ上部にナビゲーションを置いてあります。

デザインカンプを作り込む

Sunaeと同じくFigmaでデザインカンプの作成から入りました。スムーズに実装に移せるよう、Figma上ではTailwindCSSのデザインキットを使用しました。その結果デザインカンプの作成から素早くコーディングに移行でき、コーディング時は細かい調整のみとなりました。デザインのイメージを固めていたからこそ手戻りを最大限回避できたものと思います。

Figma画面

PostmanやGraphiQLでAPIの感触を確かめる

当サイトではmicroCMSとGitHubのAPIを使用しています。実装にあたり、いきなりデータフェッチのロジックを書くのではなく、まずはAPIクライアントソフトでクエリの書き方・レスポンスの形状を確かめました。さらにPostmanのモックサーバー機能を用いることで実装前のAPIエンドポイントのシミュレーションを行うこともできました。一方GraphiQLは初めて触れるGraphQLに慣れるのに役立ちました。GraphQLに感動したので、いずれGraphQLを活用したプロダクトを開発してみたいと思います。

Google Analyticsの二重計測問題を解決する

Google Analytics導入時にページビューが二重に計測されていることに気づきました。日本語の情報が少ない中でどうにか自分なりに解決させました。これに関してはいつかZennで記事にします。

Gitの仕様を理解する

GitHub APIを叩いたり、過去の自分のリポジトリを整理したりするのに、Gitの深い部分に触れる必要がありました。色々調べた結果、これまでなんとなくで使っていた(個人開発のためなんとなくでも問題がなかった)Gitについての理解を深めることができました。

これまでの理解: リポジトリ>ブランチ>コミット>ファイルの親子関係にある。各ファイルの差分を保存している
今のところの理解: ブランチはただのコミットへの参照(実体はテキストファイル)。変更されるたびにスナップショットをオブジェクトとして保存する。コミットはそれぞれのオブジェクトへの参照。つまりGitはあらゆる時点のディレクトリの状態を指す参照の集合体。

想像よりはるかに.gitフォルダは重そうです。一方でこの複雑さを見事に実装した先人らの偉大さに感動を覚えます。

きれいなコミットログにする

一貫したコミットログを作成するため、①コミットメッセージは全て英語にする ②コミットメッセージの頭に絵文字をつけて内容を分類するといった工夫をしました。結果としてコミットの一覧が非常に見やすくなり、ログも「それっぽく」なりました。メインブランチと開発ブランチについても使い分けをしています。個人開発なのでメリットは薄いですが、やはりきれいなコミットは見ていて気持ちがいいです。

コミットメッセージ

Lighthouseで高スコアを目指す

GoogleのLighthouseツールを使い、サイトの問題点を検査しました。最も頻繁に見られるトップページを中心に、要素の色味、画質、タグの使い方などを最適化しました。ついでにPWAにも対応しています。

Lighthouseスコア

Device Mashups image © Koy Carraway (Licensed under CC BY 4.0)