## はじめに
turborepoを使ったmonorepo構成でアプリを作っていて、その際に複数のフロントエンドのパッケージをcloud buildからそれぞれのvercelプロジェクトへデプロイしたかった。 

一つのパッケージを変更した際に、他のパッケージのデプロイまで実行されると嫌なので、vercelのGithub連携はやめて、CI/CDからデプロイするようにした。 

API側でGCP(compute engine)を使っている理由から、CI/CDでCloud Buildを採用した。 

**API側のデプロイの話**



 
<a target="_blank" rel="noopener" href="https://blog.1keiuu.com/posts/gcb-gce/" class="link-card"><img src="https://firebasestorage.googleapis.com/v0/b/portfolio21-56e7e.appspot.com/o/_ogp%2FeSPlvKhOJiBzH6DwBp5N?alt=media&amp;token=cbbf990f-d9f1-4732-8a17-43487392dddc" class="link-card__image">Node.jsアプリをcloud buildからcompute engineへデプロイする</a>
 



 

## アプリの構成
```
 apps/
 front/
 package.json
 ...
 admin/
 package.json
 ...
 package.json
```

monorepoを採用して複数個のフロントエンドアプリを一つのリポジトリで管理し、それぞれ別のサーバ(今回はvercel)へデプロイしています。 
今回のアプリではサイトのUIを扱う**front**と管理画面のUIを扱う**admin**があります。(実際には他にもapiなどのpackageがappsにある)
 
 

## デプロイの流れ
<div class="img__wrapper" style=justify-content:flex-start>
 <img src="https://storage.cloud.google.com/portfolio21-56e7e.appspot.com/articles/10/front-architecture.jpeg"> 
</div>

1. 変更を加えてGithubのmainへpush/merge
2. Github(Cloud Buildと連携済)がpushをCloud Buildへ通知
3. Cloud Buildが変更されたpackageをデプロイするためのトリガーを実行
4. トリガーからvercelへdeploy　

 
 
 
 
## デプロイの詳細
### 2. Github(Cloud Buildと連携済)がpushをCloud Buildへ通知
　GithubとCloud Buildを連携すればpush/mergeが通知されるようになる 

**参考**

 
<a target="_blank" rel="noopener" href="https://medium.com/google-cloud-jp/try-github-cloudbuild-integration-5149175105fb" class="link-card"><img src="https://miro.medium.com/max/1200/1*ipfJRK8KSpyTSUeFxXAomA.png" class="link-card__image">GitHubとGoogle Cloud Build の連携を試してみた！ | by Yuki Iwanari | google-cloud-jp | MediumCI/CDしてますか？. “GitHubとGoogle Cloud Build の連携を試してみた！” is published by Yuki Iwanari in google-cloud-jp.</a>
 


### 3. Cloud Buildが変更されたpackageをデプロイするためのトリガーを実行
　Cloud Buildのトリガーの作成を作成する。

　作成の際に「含まれるファイルフィルタ」にデプロイしたいパッケージのパスを追加する事で、対象のファイルに変更が加わった場合のみトリガーが実行されるようになる。　
 
例) apps/frontのデプロイ用トリガーの場合
<div class="img__wrapper" style="justify-content:flex-start">
 <img src="https://storage.googleapis.com/portfolio21-56e7e.appspot.com/articles/10/cloud-build-trigger.png"> 
</div>
 
 
 
### 4. トリガーがvercelへdeploy　
　トリガーで実行するstepでvercel cliからプロジェクトへデプロイする。 
　この時に以下のVercelのsecret情報が必要になる。　
 
 **secret情報** 
 - **VERCEL_TOKEN**: アカウント毎に作成できるToken 
 - **VERCEL_PROJECT_ID**: デプロイしたいprojecのID 
 - **VERCEL_ORG_ID**: デプロイしたいprojectを所有しているuser或いはorganazationのID 

これらはyamlに直書きしたく無いので、GCPのSecret Managerを使ってセキュアに取得する。 
 

 
<a target="_blank" rel="noopener" href="https://cloud.google.com/secret-manager" class="link-card"><img src="https://cloud.google.com/_static/cloud/images/social-icon-google-cloud-1200-630.png" class="link-card__image">Secret Manager &nbsp;|&nbsp; Google CloudSecurely store API keys, passwords, certificates, and other sensitive data with Google Cloud’s Secret Manager.</a>
 

 

## Cloud Buildの構成

 Cloud Buildのyamlファイルは以下の通り。 
```yaml
 steps:
 　- name: 'bash'
 entrypoint: 'bash'
 args: 
 - -c
 - |
 mkdir -p .vercel
 touch .vercel/project.json
 echo '{"orgId":"'$$VERCEL_ORG_ID'", "projectId":"'$$VERCEL_PROJECT_ID_FRONT'"}' >> .vercel/project.json
 cat .vercel/project.json
 secretEnv: ['VERCEL_PROJECT_ID_FRONT','VERCEL_ORG_ID']
 　- name: node:16.14.0
 entrypoint: npx
 args: ['npx','vercel','--prod','-t','$$VERCEL_TOKEN']
 secretEnv: ['VERCEL_TOKEN']
 availableSecrets:
 　secretManager:
 　- versionName: projects/{projectName}/secrets/VERCEL_PROJECT_ID_FRONT/versions/latest
 env: VERCEL_PROJECT_ID_FRONT
 　- versionName: projects/{projectName}/secrets/VERCEL_ORG_ID/versions/latest
 env: VERCEL_ORG_ID
 - versionName: projects/{projectName}/secrets/VERCEL_TOKEN/versions/latest
 env: VERCEL_TOKEN
 options:
 logging: CLOUD_LOGGING_ONLY
 timeout: 1200s
``` 

 まずstepの一つ目では、**.vercel/project.json** を作成し、SecretManagerから取得した **${VERCEL_ORG_ID}** と **${VERCEL_PROJECT_ID}** を書き込む。 

 二つ目では **${VERCEL_TOKEN}** をvercel cliのオプションに渡してdeployを実行。
 ```bash
 npx vercel --prod -t $$VERCEL_TOKEN 
 ```

 vercelの管理画面でデプロイがされていることを確認

 

## 終わりに
かなり説明はしょったけど久しぶりに記事書けた.

はじめに
turborepoを使ったmonorepo構成でアプリを作っていて、その際に複数のフロントエンドのパッケージをcloud buildからそれぞれのvercelプロジェクトへデプロイしたかった。 
一つのパッケージを変更した際に、他

monorepo構成のフロントエンドアプリをcloud build経由でvercelへデプロイする

cloud buildからcompute engineへssh(scp)している例があまり無かったのでメモ。 
## Cloud Buildの構成

Cloud Build構成ファイル(cloudbuild.yaml)は以下の通り
```yaml
steps:
 # ① Cloud Buildの実行環境にSSH鍵を作成
 - name: 'bash'
 secretEnv: ['SSH_KEY','SSH_KEY_PUB']
 entrypoint: 'bash'
 args:
 - -c
 - |
 mkdir -p /builder/home/.ssh
 echo "$$SSH_KEY" >>/builder/home/.ssh/google_compute_engine
 echo "$$SSH_KEY_PUB" >>/builder/home/.ssh/google_compute_engine.pub
 chmod 400 /builder/home/.ssh/google_compute_engine
 # ② アプリをビルド
 - name: node:16.14.0
 entrypoint: npm
 args: ['install']
 - name: node:16.14.0
 entrypoint: npm
 args: ["run","build"]
 # ③ VMインスタンスへファイルを転送
 - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
 entrypoint: gcloud
 args: ['compute', 'scp', '--recurse', 'src','root@instanceName:api', '--zone', 'asia-northeast1-b']
availableSecrets:
 secretManager:
 - versionName: projects/{projectName}/secrets/SSH_KEY/versions/latest
 env: SSH_KEY
 - versionName: projects/{projectName}/secrets/SSH_KEY_PUB/versions/latest
 env: SSH_KEY_PUB
options:
 logging: CLOUD_LOGGING_ONLY
timeout: 1200s
```

**①** Compute Engineへssh(scp)する為の鍵をCloud Buildの実行環境に作成 
 
　　ssh鍵の内容はSecret Managerに保存し、ビルド時に復号する。 

**②** アプリをビルド 

**③** VMインスタンスへscpでファイルを送信

 

## 作業の流れ 
 

1. SSH鍵を作成

```sh
 ssh-keygen -t rsa -f ~/.ssh/google_compute_engine
```

2. 作成した公開鍵(google_compute_engine.pub)の中身をVMインスタンスのメタデータに追加する
 メタデータはCompute Engine管理画面の「メタデータ」 > 「SSH 認証鍵」から編集できる

3. 1で作成したSSH鍵をCloud Buildの実行環境で使う為に、Secret Managerにシークレットを追加する
 yamlファイルでいう**SSH_KEY**と**SSH_KEY_PUB** 

4. Cloud Build構成ファイル(cloudbuild.yaml)を作成

5. Cloud Buildのトリガーを作成してビルドを実行
 
**参考** 
- SSH鍵の作成
<ogp-card :ogpindex="0" :ogps="ogps"></ogp-card>
 
 
 
## 終わりに
フロント側のデプロイフローも紹介してるのでこちらも是非 

 
<a target="_blank" rel="noopener" href="https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/deploying_red_hat_enterprise_linux_7_on_public_cloud_platforms/creating-ssh-keys-for-google-compute-engine_uploading-the-rhel-image-to-gcp" class="link-card"><img src="https://access.redhat.com/webassets/avalon/g/shadowman-200.png" class="link-card__image">5.4.3. Google Compute Engine の SSH 鍵の作成 Red&nbsp;Hat Enterprise Linux 7 | Red Hat Customer PortalRed Hat Customer Portal - Access to 24x7 support and knowledgeRed Hat</a>

cloud buildからcompute engineへssh(scp)している例があまり無かったのでメモ。 
Cloud Buildの構成
Cloud Build構成ファイル(cloudbuild.yaml)は以下の通り
steps:
 

Node.jsアプリをcloud buildからcompute engineへデプロイする

## はじめに 

Cyber Agentの[Web Speed Hackathon Vol.2](https://www.cyberagent.co.jp/careers/students/career_event/detail/id=25556)に参加するのでフロントのパフォーマンスチューニングを少し勉強しました。(執筆時は未参加) 
 
今回はLight House v6の指標についてまとめました。 
[web.dev](https://web.dev)の内容をなぞっていきます。 

## パフォーマンス測定の指標

LightHouse 6は以下の6つの指標に基づいて測定される。()の数値は重視される比率。 
 
- #### First Contentful Paint (15%) 
- #### Speed Index (15%) 
- #### Largest Contentful Paint (25%) 
- #### Time to Interactive (15%) 
- #### Total Blocking Time (25%) 
- #### Cumulative Layout Shift (5%) 
 
 
<ogp-card :ogpindex="0" :ogps="ogps"></ogp-card>
 

### 1. First Contentful Paint (FCP) 
weight: 15% 
 
> FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. 
ユーザーがページに訪れた際に最初のDOMがレンダリングされるまでにかかる時間。 
#### 考えられる原因 
- Webフォントが読み込まれるまでテキストがレンダリングされていない 
[Ensure text remains visible during webfont load](https://web.dev/font-display/) 
 
**→ 対応:** 
1. `font-display: swap`を追加 
2. Webフォントをpreloadする 

```html
 <link rel="preload" href="/assets/Pacifico-Bold.woff2" as="font" type="font/woff2" crossorigin>
``` 
 
 

### 2. Speed Index 
weight:15% 
 
> Speed Index measures how quickly content is visually displayed during page load.
どれだけ速く、ページが視覚的に表示されるか。 
#### 改善策
 
- **[Minimize main thread work](https://web.dev/mainthread-work-breakdown/)** 
[レンダリングプロセス](https://developers.google.com/web/updates/2018/09/inside-browser-part3)の根幹を司るmain threadを最適化すべし。 
main threadはHTMLのparse, DOMの構築, CSSのparseと適用, そしてJSのparse, 評価, 実行と言った、コードの大部分を扱う。 
またmain threadはユーザーからの操作(イベント)に対応する為、常に忙しいが、これを後回しにするとUXへ影響する。
**対応:** (多すぎて書ききれない...)
1. web workerを使用して、JavaScriptをmain threadで使用しない。(link: [Use web workers to run JavaScript off the browser's main thread](https://web.dev/off-main-thread/)) 
2. CSSで複雑なセレクタや数値計算を避ける。
 

```css[ダメな例]
.box:nth-last-child(-n+1) .title { /* styles */ }
``` 

3. CSSのminify, 使っていないコードの削除
4. etc...

- **[Reduce JavaScript execution time](https://web.dev/bootup-time)**
- **[Minify and compress network payloads](https://web.dev/reduce-network-payloads-using-text-compression/)** 

　MinificationとData Compressionをしよう。 

**Minification** 
　CSS,JSなどのコードファイルのminifyをしろ。(webpack v4以降なら自動でやってくれるからいらないよ👍) 

**Data Compression** 
　サーバー - クライアントのデータのやりとりを最適化しよう。GzipもしくはBrotliで。BrotliはGzipよりいいよ。 
ブラウザへ送るファイルを圧縮するには `Dynamic` と `Static` の2通りのやり方があるよ。どちらも一長一短だよ。 

**Dynamic comporession** 
リクエストが来た時にファイルを最適化するよ。手動で最適化したり、ビルド中にするより簡単だよ。けど圧縮率(?)が上がると遅延が生じるよ。 
expressではcompression middlewareライブラリを使えば静的ファイルを`gzip`でdynamic compressionできるよ。 

```javascript
const express = require('express');
const compression = require('compression');
const app = express();
app.use(compression());
app.use(express.static('public'));
const listener = app.listen(process.env.PORT, function() {
	console.log('Your app is listening on port ' + listener.address().port);
});
``` 

`Brotli`には[shrink-ray](https://github.com/aickin/shrink-ray#readme)が使えるよ〜 


・**Static comporession** 
事前に最適化して保存しておくよ。ビルドが長くなるけどアクセス時の遅延は起こらなくなるよ。 
webpackのpluginが使えるよ。 

- **[BrotliWebpackPlugin](https://github.com/mynameiswhm/brotli-webpack-plugin)** 
- **[CompressionPlugin](https://github.com/webpack-contrib/compression-webpack-plugin)** 

 

```javascript[webpack.config.js]
module.exports = {
	plugins: [
		new CompressionPlugin()
	]
}
```

 

### 3. Largest Contentful Paint (LCP) 
weight: 25% 
 
> The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport. 
viewport内で一番重い画像やテキストのレンダリング時間。 
- `<img>`
- `<svg>`内での`<image>`
- `<video>`
- cssのbackground imageなど、`url()`を使うもの

**対応**
- 画像, cssなどの最適化
- **[Optimize LCP](https://web.dev/optimize-lcp/)**
 
### 4. Time to Interactive (TTI) 
weight: 15% 
 
> Measuring TTI is important because some sites optimize content visibility at the expense of interactivity. This can create a frustrating user experience: the site appears to be ready, but when the user tries to interact with it, nothing happens.
一定数のサイトはinteractivityを軽視してコンテンツの表示速度ばかり重視している。 
 
#### 指標 
A page is considered fully interactive when: 
- The page displays useful content, which is measured by the First Contentful Paint, 
- Event handlers are registered for most visible page elements, and 
- The page responds to user interactions within 50 milliseconds. 
 
FCPによって測定された有意なコンテンツが表示され、イベントハンドラがほとんどの要素に登録され、ユーザーの動作に50ms以内でに反応する事。 

**対応**
- **[Minimize main thread work](https://web.dev/mainthread-work-breakdown/)** (またか...) 
- **[Reduce JavaScript execution time](https://web.dev/bootup-time)** (またか...)


### 5. Total Blocking Time (TBT) 
weight: 25% 
 
> TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. 
ユーザーの入力への返答がブロックされた時間(blocking portion)の合計。 
50ms以上かかる処理はlong taskとされる。 
例えば70msの処理は70 - 50で超過分の20msがblock portionとされる。 
参考: [Are long JavaScript tasks delaying your Time to Interactive?](https://web.dev/long-tasks-devtools/) 
**対策:** 
- Devtoolから時間がかかってるtaskがわかるよ~ 
[What is causing my Long Tasks?](https://web.dev/long-tasks-devtools/#what-is-causing-my-long-tasks) 

### 6. Cumulative Layout Shift (CLS)
weight: 5% 
 
cumulative(意:累計) 

レイアウトが頻繁に変わりすぎるページだとUXを損なうからよくないよ〜

**対策**
- `width`,`height`の動的な変更ではなく、 `transform: scale()`を使おう 
- `top`, `right`, `bottom`, `left`を動的に変更せず、`transform: translate()`を使おう 

## 気付き 
- 指標は６つあるが、改善策はそれぞれに固有の物ばかりでなく共通の物が多い。 
 [Minimize main thread work(JS)](https://web.dev/mainthread-work-breakdown/) 
 [Reduce JavaScript execution time](https://web.dev/bootup-time/) 

- ブラウザ(LightHouse)でJSファイルを見てもchunkされた状態になっているので、webpackのビルドプロセスを把握する必要がありそう。 
　参考: https://qiita.com/mizchi/items/418be9abee5f785696f0

次回はwebpackの最適化とかをまとめていくつもりです。

はじめに
Cyber AgentのWeb Speed Hackathon Vol.2に参加するのでフロントのパフォーマンスチューニングを少し勉強しました。(執筆時は未参加)  
今回はLight House v6の指標についてまとめました。

パフォーマンスチューニングを勉強したのでまとめた (Lighthouse編)

## はじめに
先日JPHACKS2020でハッカソンデビューしたら、色んな学びがあったのでまとめようと思いました。
 
**JPHACKSとは** 
JPHACKS(ジャパンハックス)は、学生を対象にした日本最大規模のハックイベントで、2014年より全国の複数都市で開催されています。 今年は全国を6ブロックに分けオンラインで開催されます。 
引用: JPHACKS
今年はオンライン開催で、全国から約78チーム程が参加したようです。 
 

## 開発したもの
画像分析で忘れ物を防ぐアプリ「Laff」を開発しました。 


 
<a target="_blank" rel="noopener" href="https://github.com/1keiuu/B_2009" class="link-card"><img src="https://opengraph.githubassets.com/4b58a18affd0cd09e9364781c94cb297c9c2916dec6afbb4f3bbbdf3f5ba3cdd/1keiuu/B_2009" class="link-card__image">GitHub - 1keiuu/B_2009: 画像分析で忘れ物を防ぐアプリ 「Laff」画像分析で忘れ物を防ぐアプリ 「Laff」. Contribute to 1keiuu/B_2009 development by creating an account on GitHub.</a>
 
 
 

紹介動画です(ギリギリで作ったので動画のクオリティはお察しください。。。) 


 
<a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=mVvbSJA8qvQ&amp;feature=youtu.be" class="link-card"><img src="https://i.ytimg.com/vi/mVvbSJA8qvQ/maxresdefault.jpg" class="link-card__image">画像分析で忘れ物を防ぐアプリ 「Laff」 - YouTube旅行にいく時、友達と遊びにいく時、デートをする時『持ってくるの忘れた！』という経験は誰にでもありますよね。 最近で言えばコロナのためマスクが必須アイテムになりましたが忘れてしまって無駄な出費をする事が多々あります。 そうならないために何回もチャックリストを確認して多くの時間を浪費したり、めんどくさくて確認をしない...</a>
 
 

「忙しい朝に忘れ物チェックをする時間が無い！」という問題を解決する為に開発しました。 
あらかじめ持ち物を登録しておく事で、出かける日の朝には写真を一枚撮るだけで忘れ物を教えてくれます。
 

## 使用した技術
フロントはReactNativeを使ってクロスプラットフォームのモバイルアプリ化、バックエンドにRuby on Rails、DBにPostgreSQLを使いました。

<img width="100%" height="auto" src="https://huntr-assets.s3.amazonaws.com/users/103088073/3f4e99c5-1352-4f20-b3d9-d207f5358243">

画像分析にはGoogle Cloud Vision APIを使いました。

 

 
<a target="_blank" rel="noopener" href="https://cloud.google.com/vision/?hl=ja" class="link-card"><img src="https://cloud.google.com/_static/cloud/images/social-icon-google-cloud-1200-630.png?hl=ja" class="link-card__image">Vision AI | ML で画像から情報を引き出す &nbsp;|&nbsp; Cloud Vision API &nbsp;|&nbsp; Google CloudAutoML Vision ではクラウドやエッジにある画像から有用な情報を引き出すことに加え、事前トレーニング済みの Vision API モデルを使用した感情の検知、テキストの理解などを行います。</a>
 
 
Google Cloud Vision APIを使えばこのように写真に写っている物を分析して、その名前(ラベル)を返してくれます。 
画像分析のAPIから帰ってくるラベルは英語1単語なので、その類義語をAPIから取得し、翻訳して返す事で分析の精度を高めました。 
 

<img width="100%" height="auto" src="https://huntr-assets.s3.amazonaws.com/users/103088073/9ea87c6a-92b3-4b4c-bc94-bff71190c269">

 

## 学んだ事

### 斬新かつ実用的なアイデアを考える難しさ
ハッカソン慣れしていないチームにとって一番難しい部分はここだと思います。
日頃から技術的なキャッチアップをしているだけだと「アイデアを考える」事自体あまりしないと思います。技術的な面で斬新なアプローチ(IoTやVR/AR等)が出来るメンバーが居なかったとはいえ、APIや外部サービスでカバーできるし、他のアプローチだって沢山ある筈です。
ハッカソンで良いプロダクトを作るには、限られたリソースでどれだけ柔軟に対応できるかが鍵を握るなと思いました。 

### 限られた時間でプロダクトの良さを伝える難しさ
発表時間が90秒という短さだったので、プロダクトの良さを端的かつ効果的に伝える必要がありました。（90秒というのは海外のハッカソンを参考にしているらしい)
エンジニアだけでなくCEO的な役割がいたり、バランスの良いチームは強いなと思いました。 

### オンラインで斬新なアイデアを考える事難しさ
学校などの都合もあり全員で集まれなかったので、アイデア出しもwebミーティングで行いました。　　アイデア出しにはmiroというサービスを使いました。便利でしたがフル活用出来たとは思えないし、進め方があまり良くなかったかなと思います。
アイデア出しにおいてツールはもちろん大事なのですが、それ以上にファシリテーター的な役割がチームにいると重宝されるなと感じました (そんなエンジニアになりたい。。。) 
 　

 
<a target="_blank" rel="noopener" href="https://miro.com/" class="link-card"><img src="https://images.ctfassets.net/w6r2i5d8q73s/OxZ08hm5k2id0kjQXmc0L/05bcc2743945b82009e59aa5d9c77c7d/miro.png" class="link-card__image">The Visual Collaboration Platform for Every Team | MiroScalable, secure, cross-device and enterprise-ready team collaboration whiteboard for distributed teams. Join 35M+ users from around the world.</a>
 

 
 

### 正しく恐れ、正しく急ぐ
このアイデアを思いつく前に「バーコードスキャンするだけで商品の産地やレビューがが分かる！」というアプリを開発まで始めていたのですが、APIの仕様をちゃんと理解していなかった為ボツになりました。
また、発表三日前にVue(Web)からあまり経験のないReactNative(モバイル)に変えるなど、見切り発車が多すぎました。
かと言って、ハッカソンに慣れていないチームが自分達のできる範囲の事をやっていては中々斬新なアイデアは生まれません。
限られた時間での開発は、要件定義と実現可能性の調査にしっかりと時間を取り、かつフルスピードで実装する必要があるなと感じました。 

 

## まとめ
改善点がたくさん見つかり悔しい思いをしましたが、いろんな発見が出来ました。
周りの学生のレベルの高さに驚いた一方で、追い詰められた時の自分の底力も知れました。
ハッカソンに参加すれば普段の業務と違ったチーム開発が経験出来ますし、成果物に対して結果が出るという事はエンジニアとしての成長に大きく貢献すると思います。 

皆さんの会社でも社内ハッカソンを導入してみてはいかがでしょうか？
普段と違うチームで普段と違う開発をすれば、絆が深まったり、お互いの知らない部分に気付けるかもしれません！

はじめに
先日JPHACKS2020でハッカソンデビューしたら、色んな学びがあったのでまとめようと思いました。
JPHACKSとはJPHACKS(ジャパンハックス)は、学生を対象にした日本最大規模のハックイベントで、2014年より全国の複数

学生エンジニアが初めてハッカソンに参加してみたら学びが多かった話

## はじめに
Jamstackなポートフォリオを作成しました。

 
<a target="_blank" rel="noopener" href="https://portfolio21-56e7e.web.app/" class="link-card"><img src="https://storage.googleapis.com/portfolio21-56e7e.appspot.com/articles/placeholder/lazy_with_icon.png" class="link-card__image">1keiuu's portfolioIkkei Harashima's portfolio 2021</a>
 

気づけば毎年ポートフォリオを作っていてこれで3つ目です。。 
今回はサーバーレスで管理のし易さとパフォーマンスを意識したものになりました。

過去のポートフォリオはこちら 


 
<a target="_blank" rel="noopener" href="https://portfolio21-56e7e.web.app/products/1" class="link-card"><img src="https://storage.googleapis.com/portfolio21-56e7e.appspot.com/products/portfolio19/1.webp" class="link-card__image">Portfolio 2019Ikkei Harashima's Portfolio</a>
 


 

 
<a target="_blank" rel="noopener" href="https://portfolio21-56e7e.web.app/products/5" class="link-card"><img src="https://storage.googleapis.com/portfolio21-56e7e.appspot.com/products/portfolio20/1.webp" class="link-card__image">Portfolio 2020Ikkei Harashima's Portfolio</a>
 


 

## 使用した技術
**FW:** Nuxt.js (TypeScript/composition-api)
**コンテンツ管理:** Nuxt/content , Cloud Storage 
**ホスティング:** Firebase hosting 
**その他API:** Cloud Functions 
**CI/CD:** Github Actions 

 

## 作った理由

**① 去年作ったポートフォリオのパフォーマンスが悪い** 

　React/Go/AWSの勉強を目的とするあまり、ポートフォリオサイトとしての役割を考えずに作ってしまいました。 
　結果的に費用もUXも最低な魔物が生み出されてしまいました。。。
　特にthree.jsの部分はSPで見るとsafariが落ちるくらい重く、やっつけで作ったせいかチューニングも面倒になって放置状態。 
　これに反省して、「Jamstackでパフォーマンス最高なで管理し易いサイトに作り直そう！」と決心しました。 
 
**② 去年作ったポートフォリオは管理画面を作ってないのでコンテンツの更新が面倒** 

またしても2020年度版の欠陥なのですが、当初作る予定だった管理画面を作る気力がなくなってしまい、未だに内容を更新するにはEC2にsshしてSQL叩く必要があるという状況のまま。。 
冷静に考えてもポートフォリオでDB用のEC2インスタンス建ててたのアホすぎる。。。

**③ nuxt/contentを使ってみたくなった** 

はじめはmicroCMSでJamstackを目指して作成していたのですが、たまたま聞いていた[UIT INSIDE](https://uit-inside.linecorp.com/)のポッドキャストでnuxt/contentを知り、コンテンツの管理がめちゃくちゃ便利そうで使ってみたくなりました。 
しかもマークダウンで簡単にブログが作れる、、、！

②の失敗を踏まえても、Githubで管理したjson,マークダウンだけでコンテンツの管理ができるのだから、個人開発のポートフォリオに最適だと思いました。


 

## 工夫した所 

**※ (ここら辺は詳しく別記事を書こうと思います！)**

### OGP画像の動的生成 
　Twitterなどでシェアした時にQiitaっぽいOGPが表示されるようになります。 
　Cloud Functions × Cloud Storageで実装しました。 
　以前まで無料だったCloud Functions(Firebase)もnode v10より有料（従量課金）との事、、 
 
**参考にした記事** 
[絶対にお金を払いたくない精神での動的OGP生成は辛い ](https://blog.ojisan.io/dynamic-ogp) 
 

### 記事内で表示するOGP情報の取得 
　Nuxt/Contentで書かれた記事内で外部ページのOGPを表示する為の実装が必要だったので、URLからOGP情報を取得するAPIをCloud Functionsで作成しました。 
　~~ただ、ここはページ表示の度に都度取得しているので、純粋なJamstackっと言えるのか？と言う気持ち。。~~ 
 
 **1/18更新: OGP情報の取得をビルド時に変更した為改善されました！**
 
 

### CI／CDを設定して記事ページの自動更新 
　このサイトはSSGでビルドしているので、記事などのコンテンツを更新する度にビルドをかける必要があります。 
　そこで、Github Actions × Firebase Hostingを使ってCI/CDを構築しました。 
　この組み合わせは設定もめちゃくちゃ楽なので、短い期間での個人開発ではかなり使えると思います。 

以前Qiitaの記事にしました。 


 
<a target="_blank" rel="noopener" href="https://qiita.com/ikkei12/items/0f0c2d95bdd3b54d6bac" class="link-card"><img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fcdn.qiita.com%2Fassets%2Fpublic%2Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png?ixlib=rb-4.0.0&amp;w=1200&amp;mark64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZ0eHQ9TnV4dCVFMyU4MiVBMiVFMyU4MyU5NyVFMyU4MyVBQSVFMyU4MiU5MlNTRyVFMyU4MSVBNyVFMyU4MyU5MyVFMyU4MyVBQiVFMyU4MyU4OSVFMyU4MSU5NyVFMyU4MSVBNkNJJTJGQ0QlRTMlODIlOTIlRTMlODElOEElRTYlODklOEIlRTglQkIlQkQlRTMlODElQUIlRTglQTglQUQlRTUlQUUlOUElRTMlODElOTklRTMlODIlOEIlRTMlODAlOTBHaXRIdWIlMjBBY3Rpb25zJTIwJUMzJTk3JTIwRmlyZWJhc2UlMjBIb3N0aW5nJUUzJTgwJTkxJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MDM1NTgyYTBjODAzNjZmOTE5ZjczNjBiNzA1ZjY0NQ&amp;mark-x=142&amp;mark-y=112&amp;blend64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaWtrZWkxMiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzJkYmE2ZmJkZWNlNzQyMWQ4ODFhM2NmNWQzNTBiNGM&amp;blend-x=142&amp;blend-y=491&amp;blend-mode=normal&amp;s=259057ef690647362da749bea298742f" class="link-card__image">NuxtアプリをSSGでビルドしてCI/CDをお手軽に設定する【GitHub Actions × Firebase Hosting】 - Qiita</a>
 

 


 

## 最後に

修正する点はまだまだ沢山あるのですが、なかなか管理しやすくパフォーマンスも比較的良いサイトが一旦は出来上がったのでは無いかと思います。 
使った技術が最小限かつパワフルでとても使いやすかったと思います。 
特にNuxt/contentが最高でした！ 
あとは相変わらずFirebaseは個人開発の味方ですね。

これからはQiitaやzennに加えてこのブログでちょっとした記事を書いていこうと思うのでよろしくお願いします！

はじめに
Jamstackなポートフォリオを作成しました。

1keiuu's portfolioIkkei Harashima's portfolio 2021


気づけば毎年ポートフォリオを作っていてこれで3つ目です。。今回はサーバー

1keiuuのブログ

monorepo構成のフロントエンドアプリをcloud build経由でvercelへデプロイする

Node.jsアプリをcloud buildからcompute engineへデプロイする

パフォーマンスチューニングを勉強したのでまとめた (Lighthouse編)

学生エンジニアが初めてハッカソンに参加してみたら学びが多かった話

Jamstackなポートフォリオを作成しました