ブログのNext.jsのバージョンを12系に上げた

この1年はどうだっただろう。点数をつけるとしたら30点くらいだろうか。正直転職からの労働時間は前職時代と比較して60%くらいになってしまった。自分を律することができずダラダラしてしまった時間が多いと感じた。身についた技術はあったが、正直中途半端にしか習得できなかったな、という感覚が強い。DDDも自分としては

> Clean Architectureっぽくレイヤーだけ区切ってあとはよしなに実装したら？

という味気ない塩梅に落ち着いた。それよりテストコード書こうぜ。そんな完璧なモデリングを最初からできるはずもないし、維持し続けるのも難しいよ。それより変更した時に守ってくれるのはテストコードだけだよ。ドメインモデリングのドキュメントも確かに大事だけど自分だったら同じ分だけのテストコードがあった方が嬉しいかな。テストコードは裏切らないからね。DDD * TDDが結局一番だよ。

DDDやソフトウェア設計もだけど、本当はOAuthだったりTerraformだったりSQLだったりデータ構造・アルゴリズムだったりもっと色々な技術をこの1年で身につけるつもりだったんだけどなかなかうまく行かなかった。改めて自分の頭の悪さと向き合わざるを得なかった1年だった。自分より強いエンジニアとの差を痛感した。色々試行錯誤してみたものの、根本的にキャッチアップのスピードが自分は人より遅いらしい。これは致命傷。亀とウサギの話じゃないけど、現実の強強エンジニアといううさぎは途中で止まってくれはしない。差は開いていく一方なのでなんとかして亀はウサギになるしかない。

とかとか、上記みたいなことを最近考えることが多くて。こんなことばっかり考えていると自分が果たして2~3年後もエンジニアとして第一線で生き残れているのだろうか？と不安になる。自分としては将来的にはSREみたいなDevOps的なポジションのエンジニアになりたいな〜とはぼんやり思っているものの、目の前のアプリケーションコード１つ満足かけないのに何を言ってるんだ？みたいに思ってしまう。自分にはこういうことをざっくばらんに相談できるエンジニアの知り合いもいないので自力で切り抜けるしかないわけで...。

テックリードのいる会社さんで副業して知り合いを増やしたり手持ちの技術や経験を増やすのがいいのだろうか？自分の技術スタックとしては

- Rails(たぶんできる)
- React(たぶんできる)
- Vue.js(ちょっと)
- AWS(VPCとかEC2とかRDSとかは自力で立てられるくらい)
- DDD, Clean Architecture(だいたい概念言われたら分かる)

みたいな感じ。いや、改めて見ても貧弱w。これくらいのスペックだとやっぱ厳しいよな〜。OSSとかにガンガンコミット出来るのが理想なんだけど、そもそもOSSの`good first issue`すらまともに追えないレベルだし...。これから先どうやってエンジニアとして生き残っていくか。相談乗ってくださる方、師匠になって下さる方募集中。今日はここまで！

1年を振り返り今後のキャリアを考える

スポットでとあるスタートアップで約1年間AWS上で運用されているLaravelアプリケーションのインフラをスケールできるよう改善して欲しいという依頼をされたので見てみることに。

これが中々どうして手強いのものでした。

その会社さんはエンジニアリソースが限られており、インフラに明るいエンジニアがいないのでIaCやコンテナ運用は厳しいという前提があることを頭に入れて頂いた上で読み進めて頂けると幸いです。

*結構ざっくり書いてあるので所々抜けている記述があると思いますが備忘録なので許してください...*

# 調査編
## Part1
WordPressを生業としていたCTOの方がインフラを作られたという情報を念頭に置いた上でAWSのコンソール画面で見てみることに。そこにはデフォルトVPC上のパブリックサブネットにEC2がポツンと1台立たずんでいるだけでした。

> Laravelアプリケーションを運用しているならS3やRDSはないのか...？

と疑問に思い、作成したご本人であるCTOに聞いてみましたがそもそも`S3`や`RDS`は知らないとのこと。では画像やMySQLのデータはどこに保存しているのですか？と聞いてみたらEBSに全て突っ込んでいるという解答を頂きました。バックアップは一切取得していないそうです。EBS消失したらどうするんだろう。

また、AWS操作のログを知りたくなったのでCloudtrailで操作ログを見てみたらルートアカウントで操作されていました。IAM...

## Part2
さて、コンソールからではEC2インスタンス内に何が入っているか分からないのでSSH接続して入ってみました。するとなぜか事前に共有されていた情報とは違い

**合計6つのLaravelアプリケーションが1台のEC2上に相乗りしていました**

DBに至ってはEC2インスタンス内のMySQLになぜか10個くらいDBが入っていました(正確には数えていません)。

ヒアリングの結果、サービスの歴史的経緯から本体のLaravelアプリケーションの亜種が5つ相乗りしており、EC2に来たリクエストをapacheで振り分けていました。経験未熟な自分はこの現実を見てゴールが何か分からなくなりました。しかし正体不明の野良バッチなどがなかったのは不幸中の幸いと言うべきでしょうか。

# ゴール策定編
混乱しても仕方がないので、状況を整理してどうして欲しいのかを話し合いました。
決まったのは、

- 6つのLaravelアプリケーションのうち1つは完全に独自仕様なので別インスタンスで運用したい
- 残りの5つは近い将来統合する予定なので統合できるよう稼働させて欲しい
- デフォルトVPCを脱却して専用のネットワーク環境をとりあえずいい感じに作って欲しい
- 大事なデータが入ったEC2上のMySQLを何とかセキュアに運用できるようにして欲しい

というものでした。正直インフラ(AWS?)の基礎知識をもった人がいなかったので、誘導尋問っぽくなった感は否めませんが、自分の中ではベストな提案をできたと思っています。

# 検証編
まず実験できる環境が必要だと判断し、ステージング環境を作ることにしました。VPCからサブネット・セキュリティグループ・ルートテーブルなど一式作る必要があったので若干時間がかかりました。本番環境で稼働しているEC2からAMIを作成し、ステージング環境のVPC上で作成したAMIからEC2を起動して実験しました。AMIを作成するとき`再起動しない`にチェックをつけないとオリジナルのEC2が再起動してしまうので気をつけて下さい。

EC2上のMySQLを処してRDSへ移行するため、mysqldumpでデータをダンプできること・RDSへインポートできることを確認しました。レコード数が大したことなかったので[DMS](https://aws.amazon.com/jp/dms/)は使いませんでした。

# 移行編
移行当日(深夜)はユーザに一切EC2にアクセスされて欲しくないので全段にELBを挟んでユーザにはELB側でメンテナンス画面を出し、自分達のIPアドレスからはEC2を含むターゲットグループにリクエストを流すという方法を取りました。

[[AWS]ALBだけでメンテナンス画面を表示させる](https://blog.adachin.me/archives/10330)

ドメインレジストラにはRoute53ではなく某国産ドメインレジストラを使っており、AレコードでEC2のElastic IPを指定していました。`terraform apply`で一発！という手段は取れない事が確定したので、温かみのある手動操作でAレコードを消してCNAMEでELBのDNSを入力して反映を待ちます。ELBのIPアドレスは可変なのでちゃんとDNSを指定しましょう！

メンテナンス画面が表示される事を確認出来たところで

1. 本番EC2からAMIを取得して新規で作成したVPC上にEC2を1台ずつ起動
2. mysqldumpでsqlデータをダンプ
3. 事前に立てておいたRDSにダンプしたデータをインポート
4. Laravelの`.env`内のDBに関する環境変数をRDSの値に書き換え
5. ELBのターゲットグループに新規で立てたEC2を入れる
6. 疎通できているか画面をチェック
7. ELB側で固定で返していたメンテナンス画面表示のルールを削除

という感じの流れで行いました。記憶を掘り起こして書いてるので間違ってるかもです。

# 感想編
本番環境を操作するのは神経をすり減らしますね。また、自分のようなインフラに明るくないエンジニアが移行作業を完遂できたのはELBあってこそだなと痛感しました。ELBマジ感謝。

お察しの通りまだアプリケーションの構成としてはELB, EC2, RDSの構成になっており、EC2のMAZ対応が出来ていないのでこの後はElastic Beanstalkへの移行というミッションが控えています。頑張ります！

1年間運用されたEC2を処す ~デフォルトVPC脱却編~

### 概要

念願の自分のドメインを取得しました。

エンジニアとしての名刺、くらいの気持ちで買いました。

仕事はなんとかこなせてます。

TwitterでDMくれればいつでもオンラインランチします。

これからもよろしくお願いします。

### Tech系の話

一応このサイトはtechでサブドメインを切っているので技術系のブログとして運用していこうと思っています。

流石に上記の文章だけで投稿するわけにもいかないかと思ったので少し技術的な話を。

*DDDはいいぞ！！！*

~完~

23歳の意気込み

## 1年前と比べて

1年前の自分が使っていた技術・・・ Rails, jQuery

今・・・ TypeScript, AWS

これだけ違う

なんなら所属している会社も違う

## 本題

今年はオライリーのTypeScriptの写経をしつつ実践TerraformでIaaSを勉強します。

どちらも業務に必ず役に立ちますし、自分の弱点だからです。

もちろん他にも勉強すべき事は山のようにありますが優先度を考えて上記の2点に絞りました。

がんばります。

年末にかけてやること

スタートアップでよく言われるのが

> 泥臭く頑張る事が成功への〜〜

みたいな言葉。

事実だとは思う。

ただ真実ではないとも思う。

というのも成功しなかったら泥臭く、ではなく泥でしかないから。

成功者は過去の日々を`泥臭く頑張る事の積み重ね`と表現して謙遜する。

それはこれから挑戦する人々への戒めも含めての言葉だと思う。

しかし、まだ何の結果も出していない人がその言葉を使うのも違うな、と思った。

僕は成功できず、スタートアップから逃げた言わば敗走者です。

まあ、別に僕は創業していないのでそもそもここまで言えるのか、というのはありますが笑。

まあ、一応曲がりなりにも1年半唯一のフルコミエンジニアとしてWebからモバイルアプリまで面倒をみたので多少は許されるでしょう。

そんな僕からすれば、成功を信じて目指しコードを書き続けたあの日々を、あの時間を`泥臭く頑張る事の積み重ね`と形容することはできません。

何しろ、結果がまるで出ませんでしたから。

最大4人いたのも1人辞め、また1人辞め、最後に残った僕もメンタルを崩して辞めました。

もちろん、現時点で語るのは時期尚早というのも事実でしょう。

しかし、現時点で何らかのトラクションが出ていないのも厳然たる事実です。

成果至上主義のこの業界で何も為し得ていないのに`自分はこれだけ頑張りました`と自分で語るのはあまりに厚顔無恥な事ではないかと今は思っています。

ですから、僕はこれからも自ら誰かにスタートアップにいた時の事を語ることはないでしょう。

しかし、どこかでこの事実と正面から対峙し、認めざるを得ない日が来るのだろうな、とも思っています。

その時は自分の言葉で正しく、1ミリも美化せず伝えられればと思います。

泥の価値

## 入社報告

12/1付けでクラウドワークスに入社致しました。

会社では新規事業開発部に配属して頂き、日々業務に励んでいます。

実は11月から業務委託として働いてはいたのですが念のため外部に向けての発信はしませんでした。

新規事業開発部ということや会社がフルリモート制を敷いている事などからあまり前職時代との変化はありません。

立ち上げの時期なので技術選定や要件定義のミーティングを行うなど、本当になんでもやります！って感じです。

自分自身の感覚で言うと「帰ってきた」という言葉がしっかりきます。

どうしても前職を辞めてからはいまいち身の入らない生活を送ってしまっていましたが、前線に復帰出来たことで良い緊張感を持って仕事に臨むことが出来ています。



入社エントリ

人は飛ばした本番環境の数だけ強くなれる

本番環境でやらかしちゃった人 Advent Calendarを読んで思うこと

## 最近やったこと

新しい会社に入ってから新規事業部に配属して頂きました。

自分が今までやりたかった領域なのでとても嬉しいです。

これまで小さいものも含めて3,4回ほど新規事業の立ち上げを経験してきましたが成功ないし売り上げが立ったことはありません。

なので今回は絶対に売り上げを最速で立たせてみせる！という意気込みです。

会社に業務委託としてジョインしてから3週間でやったこと(勉強した内容)をざっと振り返って見たいと思います。

- DDD
- kotlin + Spring Boot
- Prisma
- AWS (VPC, EC2, RDS, Elastic Beanstalk)
- Docker

DDDは今回の開発で採用されている、かつ僕自身ずっと勉強したかった内容だったのでTypeScript + Expressのリポジトリを写経したり松岡さんのDDD本を買って読んだりしながら少しずつ勉強しています。

ただ最近そもそもオブジェクト指向をわかっていない自分はまずオブジェクト指向を勉強するべきなのでは・・・？と危機感を感じたりしています。

技術選定の過程でkotlin + Spring Bootが一時あがっていたので1週間ほど触っていました。

と言ってもflywayとMyBatisを触っていただけでkotlinの文法は何も知りません・・・。

PrismaはTypeORMがイケてないと聞いたことがあったのでとりあえず触ってみた感じです。

チュートリアルが終わった程度で正直TypeORMと比べて何が優れているのか分かりませんでした。

AWSは今回インフラも自分たちでなんとかしないといけないということで急遽重い腰を上げて勉強し始めました。

勉強にサーバ代がかかるので今までやってこなかったのですがそろそろやらないとヤバイ、という危機感はあったので良い機会です。

ただ同時に今まで勉強してこなかったDockerも一緒に勉強しているので頭がこんがらがっています。

ただ令和にもなってDockerfileの一つも書けないのではエンジニアを名乗る資格がないとも思っていたので恥を承知でキャッチアップしたいと思います。

ちなみに僕は今までRailsべったりの人間だったのでSQL1本まともに書けません。

今後自分がエンジニアを生業としていく上で自分が全く触ったことな無い領域で勉強が必要なのは

- 認証・認可
- GraphQL
- NoSQL
- IaaS(Terraform)
- サーバレスアーキテクチャ
- アルゴリズム(競プロ)
- 関数型言語(Scala, Haskell)

あたりでしょうか。

とにかく勉強・知識・経験不足です。

本当に泥をすする覚悟でやっていくしか無いと思っています。

よろしくお願いします。

師走を迎えるにあたって

## 技術選定をする時とは

## 技術を選定する際に考慮する4つのポイント

#### 学習コスト

#### 周りに聞ける人はいるか

#### 将来的にエンジニアの採用の強みになるか

#### 中長期的にスピード開発が出来るか

## 結局最後は諦めが肝心

[SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”](https://logmi.jp/tech/articles/321982)

[技術的負債の上手な積み上げ方・返し方](https://logmi.jp/tech/articles/321990)

技術選定をする時に考えること

## エンジニアはどうやって強くなるのか？

世の中の一流企業ではエンジニアの育成システムというか、どうやって自前で強いエンジニアを育てていくかという議論が日夜行われている。

Qiitaや個人ブログでそのような記事は少し探せばいくらでもヒットするしどれも傾聴に値するものばかりだ。

しかし、自分の短いエンジニア人生を振り返った時そんなものとは無縁だった。

一番最初のインターン先では右も左も分からぬまま実戦でコードを書いたし、次の会社ではエンジニアの上司はおらず、フルコミのエンジニアがそもそも自分しかいない中でひたすらコードを書き続けた。

正直、かなり効率は悪かったと思う。

何度「自分にエンジニアの師匠がいれば」と思ったことだろうか。

自分と同年代のエンジニアや年上の方々がTwitter上でテックリードに就任された事を報告していたり、CTOとして活躍されている姿を見て心底悔しく感じた。

エンジニアとして差が広がっていく一方の状況を指をくわえて見ている他なかった。

自分も単純なコーディング時間なら変わらないはず。

プログラミングに対する熱意も負けてはいないはず。

技術的負債に対する責任・意識も同年代にしては低くはなかったと思う。(結局自分に全て返ってくるというのもあったが)

しかし、お世話になっていた先輩が何度も仰っていた言葉があった。

「僕は誰かに教わったことはほとんどないよ。分からないことは全部調べて解決してきた。」

最初は信じられなかった。そんなこと、あるはずがない。

独学であの領域に到達できるなら苦労はしない、と。

しかし、あれから強いエンジニアと会っていく中で、疑念は確信に変わった。

今なお第一線で活躍されているエンジニアは勝手に一人で強くなって、勝手に一人で結果を出していた。

信じられなかったが事実だった。

僕はまだその境地に到っていない。

何か新しい言語・技術を扱う時書籍(2次情報)を探し、座ってお行儀よく勉強しようとしてしまう。

これでは今最前線で闘っている方々に追いつけるわけがない。

とにかく汚くて良いからアプリケーションコードを書くこと。

とにかくこれを徹底していくように心掛けている。

汚くても良いから動くコードを実装してからその言語ではどう書くのが正解なのかを調べていけば良い。

最初からきれいに一本道で行こうとするから失敗するのだ。

現在は仕事でKotlin, Spring Bootを扱う可能性が高いので写経しているがとにかく自分の手を動かしてプロダクションに近いコードを書くようにしている。

文法や言語の機能を勉強をおろそかにするつもりはない。

しかし、いちいちそこを本を買って勉強していたのではサービスで使えるようになる日がいつ来るかわかったものではない。

分からなかったらその都度リファレンスを参照して調べれば良い。

まず動くものを作る。

汚かったらアーキテクチャを再考してリファクタリングを敢行すれば良いだけの話。

話が逸れてしまった。

今回は`エンジニアはどう強くなるか`というタイトルだったか。

## 結論

一流のエンジニアは誰かの助けを求めずとも勝手に強くなる。

ちなみに再現性があるかと言われたら低いと思う。

もしこれを万人ができるなら世の中にスクールなどのエンジニア養成機関は乱立していないだろうし、企業がエンジニア育成文化を推進するはずがない。

これを出来るのはごく一部の才能ある人の技なんだとは思う。

しかし、それができなくては一流になれないというのも一定の事実だと思う。

自分が出来るかどうかさておき、一流を目指すことを諦めるような真似はしたくない。

一流を目指すことを諦めた時点でそいつは敗北者だ。

俺はまだそうなりたくはない。

なれるかどうか挑戦してから決める。

というわけで、勝手に強くなって勝手に結果を出すべく明日からも頑張ります。

勝手に強くなります

## なんで柔軟体操？

まあ、普通の人はそう思うだろう。(僕ならそう思う)

少なくとも僕の周りにいる人で柔軟体操をしている人を見た事がない。(僕が知らないだけの可能性も大いにあるが)

ほとんどの人は健康に気を遣って筋トレやら栄養バランスの取れた食事などをしている。

ただ僕は元来捻くれ者なので人と同じことをやる事が好きではない。

筋トレをもいずれはしたいと思っているがブームが過ぎた頃に独り静かにやろうかな、と思っている程度。

他の人があまり意識を置いていない分野でかつ健康に良さそうなもの・・・。

そこで思いついたのが柔軟体操だった。

中高で陸上をやっていた時、柔軟体操(ストレッチ)には苦手意識があった。

身体が硬かったためハードル走は断念した。(そもそもあまり興味を惹かれなかったのもある)

これを機に苦手分野を克服するのも良いかもしれない、くらいの意識だった。

思えば僕の尊敬するアスリートは柔軟性が高かった。

イチローは言わずもがな、今シーズン限りで引退された藤川球児選手も身体の柔らかい選手として有名だった。(投球フォームのスライド幅が平均選手は5足半~6足半のところを藤川選手は驚異の7足半だった)

そんなこともあり柔軟性を高めてから筋トレをすれば多少はましな運動が出来るようになるのでは？と考えた。

始めてから1週間が経ったが特段変化は見られない。

とりあえず年末までやってみてどれくらいの成果が出るか待ってみよう。

I字開脚とかできたら話のネタくらいにはなりそう。

## 最後に

来週から2週目に入ります。

お仕事頑張ります。

柔軟体操を始めました

## どんな感じ？

フルリモート・フルフレックスなので正直あまりまだ会社の一員になった、という感覚が無いです！(そもそも正式な入社は12月からで今月は業務委託契約)

僕が配属されたチームのメンバーの方々はとても優しく、僕の方からガンガン話しかけやすいのでとても働きやすいです。

仕事のしやすさが全然違いますね笑

## 仕事内容

ワークスタイルというか、やっている事はスタートアップ時代とほとんど変わらないです。

新規事業の立ち上げなので技術選定や仕様の把握などです(コーディングはまだ)。

自分が今までやってきたことではありますが、要求されるレベルはこれまでよりもっと高いものなので期待に答えられるように頑張る所存です。

## 心意気

まずチームの一員として良い結果を出せるよう頑張っていくだけ、という感じです。

より速く、より正確にコードを書く。

これが今の僕の目標です(漠然とした目標でごめんなさい😅)

ただ、本気でそう思っているのも事実です。

それほど新規事業というのは要件が変わりやすく、求められるスピードは高い。

それに対してどれだけ応えられるかというのはエンジニアの腕の見せ所では無いでしょうか？

また、僕自身エンジニアとしてまだまだ未熟な身ではありますがいちメンバーとして会社の利益に貢献していく事はマストです。

ただコードを書くのではなく売り上げに繋がる機能、サービスを世の中に提供していければと思います。

とにかくやっていきます。

また、個人的な目標として

> この人を雇って良かった

と思って頂ければベストです。

1週間が経ちました

NextとFirebaseで開発するにあたって参考にしたサイト・学習ロードマップ

# TL, DR
- Next.js便利
- Vercel最高
- Firebaseいいぞ

## Next.jsを入門してみた

この1年でかなり進化したと噂のNext.js。

きっかけはこちらの記事。

https://qiita.com/thesugar/items/01896c1faa8241e6b1bc

はてブでもかなりバズっていたのでご存知の方も多いのではないかと思う。

とりあえず上記の記事の通りにチュートリアルを進めてルーティングであったり、`getStaticPaths`と`getStaticProps`の違いや`Vercel`へのデプロイをなんとなく掴んでからNext.jsのリポジトリのexampleディレクトリの中から自分のやりたいものに近いやつをクローンしていじってたりした。

具体的にはこれですね。

https://github.com/vercel/next.js/tree/canary/examples

かなり豊富でメンテナンスもこまめにされているので一度は覗いておいて損はないと思います。

他にはNext.jsを触っている方が作ってらっしゃるボイラーテンプレートやサービスを参考にさせてもらったりしました。

https://github.com/watanabeyu/next-firebase-hosting

https://github.com/sadnessOjisan/ogpng

https://github.com/wawoon/blog

軽く触ってみて感じたのは

> フレームワークってこういうのか〜

というもの。

ルーティングであったりnpm scriptsであったりビルドの設定だったり色々。

デフォルトでTypeScriptを使えるのも良いよね。

自分としてはNext.js側で色々やってくれるので開発に集中出来るのが良いなと思いました。

特にVercelと組み合わせた時のDXは神！(知らんけど)

Nuxtを触った事がないので詳しくは分からないけど正直みんな一回はNext.js触ってみて欲しい。

## ハマったところ

### 環境変数の扱い

詳しくはここ読んで！(丸投げ)

https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser

詳しく書くと、Firebase使うのにconfig/firebase.tsで

```ts
  firebase.initializeApp({
    apiKey: process.env.API_KEY,
    authDomain: process.env.AUTH_DOMAIN,
    databaseURL: process.env.DATABASE_URL,
    projectId: process.env.PROJECT_ID,
    storageBucket: process.env.STORAGE_BUCKET,
    messagingSenderId: process.env.MESSAGINGSENDERID,
    appId: process.env.APP_ID,
    measurementId: process.env.MEASUERMENTID,
  });
```

こんなの書くじゃないですか？

で、これの中の`process.env.PROJECT_ID`が読み込めないというエラーが出る。

他は読み込んでるのになぜだ〜と小1時間くらいハマって公式ドキュメントをgoogle翻訳使って読み直したら書いてあった。

> This loads process.env.NEXT_PUBLIC_ANALYTICS_ID into the Node.js environment automatically. Allowing you to use it anywhere in your code. The value will be inlined into JavaScript sent to the browser because of the NEXT_PUBLIC_ prefix.

どうやらブラウザ側で呼び出す環境変数は先頭に`NEXT_PUBLIC_`を付けないといけないらしい。

いや、初見殺しの仕様だな！！！

みなさんお気をつけて。

あとはVercel側で実際に環境変数を入力する所とかはこの記事を参考にしたら大丈夫かと思います。

https://qiita.com/Ikko_Kojima/items/c855635209fa6045a88d

### Google Lighthouseでhtmlのlangが設定されてないと言われる

htmlで日本語のサイトだと`lang = ja`を設定するじゃないですか？

でもNext.jsでindex.htmlファイルはないしなあ・・・と悩んでいたところ、どうやら`_document.tsx`を作成したら良いらしいと判明。

```ts
import React from 'react';

import Document, { Html, Head, Main, NextScript } from 'next/document';

export default class MyDocument extends Document {
  render() {
    return (
      <Html lang="ja">
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}
```

こんな感じで作成したら無事設定できました。

## Vercelどうよ？

Firebaseにホスティング機能があるのでそっちでも良いかと思ったのでがせっかくNext.jsを触っているのでデプロイはVercelでしました。

pushしてGitHub上でURLを発行してくれるのとか便利ですよね。

あと画面自体も見やすいので気軽に触れました。

料金が基本無料なのもポイント高いです。

あまりガッツリ触ってないのでこれくらいしか感想ないです。

ごめんなさい！！！

## 最後に

一緒にNext.js勉強してくれる仲間募集中。

以上！！！！

Next.jsとFirebaseとVercelで新しくブログを作り直した件について

## webpack, next.js, eslint, and so on

とりあえず`create-react-app`におんぶに抱っこだったので自力でReact + TypeScript + Webpack + Firebaseのテンプレートリポジトリを作れた。

自分の場合ミドルウェアはredux-saga使うし、その他諸々のライブラリ(ルーティング, CSS in JS, フォームバリデーション)もいつも一緒でいちいち

```
$ yarn add redux react-redux redux-saga ...
```

みたいに打っていくのがだるくなったのでテンプレートリポジトリを作った。

あわよくばpublicにしたら誰かプルリクくれないかな〜、くらいのノリで公開しました。

Firebaseはこれからガンガン使っていきたいですね。

まだセキュリティルールの部分や大規模開発でのFirestoreの設計やclient side joinなど勉強できていない部分も多いのでこれからキャッチアップしていきたいです。

あと今日eslintの設定の記事をいくつか読んで感じたのですがeslintの変更が本当に頻繁過ぎ&難しすぎるのダブルコンボでマジ勘弁。

あれ初心者が軽い気持ちで設定ファイル作れるもんじゃないでしょ・・・。

誰か.eslintrc.jsの決定版！みたいなやつを公開してくれないかな(切実)

僕自身はそんなにこだわりとかないのでとにかくそこで時間を取られずに開発に集中したいと思うばかり。

## お前はいつからフロントエンドに転身したんだ？

いや、別に仕事柄フロントを扱う時間が長くなってしまっただけであまりフロントに強い思い入れがあるわけではありません。

もっと言うと自分はフロントよりサーバの方が向いていると思っている(UI, UXを考えるのが苦手, CSSなんもわからん, サーバサイドでアーキテクチャを議論したり学んだりするのが好きなど様々な理由がある)のでフロントだけでなくきちんとサーバサイドの勉強もしていきたいと思います。

その一環として、N予備校の無料キャンペーンに応募していたことを思い出しScala入門コースを昨日から触ってたりします。

エンジニアとしてScalaといえば誰でも一度は触ってみたい言語なのではないでしょうか？(俺調べ)

まだHello Worldくらいしか出来ていませんが、いつかちゃんとAPIを作れるくらいにはなりたいですね。

サーバサイドで型のある言語で開発できるようにならないとこの先厳しいな、と思っているので・・・。

Scalaを選んだのはかけたらカッコいいな！と思ってる&N予備校のコースにあったからだけでそれ以上に深い理由はないです笑

## 手記

#### やはり俺の青春ラブコメは間違っている　１１巻を読んで

高校時代振りに読み返した。

別にあの時から何か人間的に成長できたわけではないということを思わせてくれる本だった。

というのも感想が全く同じだったからだ。

彼ら、彼女らは自分たちの求められる役割に徹した結果、身動きが取れなくなっているように見えた。

雪ノ下陽乃はそれを的確に見抜いた上で拒絶している。

別にそのあり方がどうだとか言うつもりはない。

少なくとも今の僕にそれを語る資格はないだろう。

比企谷八幡は優しいし、雪ノ下雪乃は弱く、由比ヶ浜結衣は残酷な人物だ。

高校生活という限られた時間の中で、偶然にも不幸な巡り合わせで邂逅してしまったからこそ生まれた人間模様。

いまだに僕はその結末を見届けられないでいる。

次の巻を手に取る日はいつになるのだろうか？

細心而剛胆

## 多分今OVA回だと思う
ほんとここ最近はReactとFirebaseをいじってます！

と言ってもここ2,3日はReact.jsしか触れてませんがw

CSSの管理はとりあえずスター数と採用実績の多い`styled-components`でいくことにしたのでそこらへんの勉強というかコードを少しずつ書いてます。

`Tailwind`なんてものもありますがちょっと今の僕では使いこなせそうにないのでまたの機会にしようかなと思ってます。

今日もこのブログのOGP画像の修正だったりフッターの追加だったりトップページのレスポンシブ対応何かをしてました。

おかげでほんの少しstyled-componentsを理解できたので良かったです。

VS Codeのstyled-components用のプラグインをインストールしたおかげでシンタックスハイライトがつくようになったのが個人的には収穫でした笑

## 最終話までのマイルストーン

いや〜、シーズン1は波乱万丈でしたね！

僕もまさかこんな展開になると思っていませんでした。

おそらくあと残り3,4話くらいだと思うのですがどうやって決着をつけるのか、新天地で果たして活躍できるのか等シーズン2への布石も十分に打った上での展開に目が離せそうにないですねw

自分としてはとりあえずハッピーエンドでさえいれば満足です。

どんな展開になるのであれとにかく全力を尽くして欲しいと願わんばかりです。

がんばれ！

閑話休題

## 今回のアップデート内容

タグ機能を付けました。

タグごとの記事一覧ページもすぐ追加しますのでもう少々お待ちください。

Firestoreの`subcollection`に少し戸惑いましたがとりあえず実装できて良かったです。

タグ機能を追加しました

## TL, DR

- Firebaseの勉強がてら自分用のブログサイト(これ)を作成しました
- Firebaseはすごいぞ(今更・・・)

## 作ったきっかけ

色々あって直近でFirebaseでサーバレスアプリケーションの開発をするかもしれない、ということになった(言い方が曖昧だけど確定ではないのも事実なのでこれくらいまでしか言えない)。

じゃあ流石に手を動かして自分でなんか作るか、何を作ろうとぼんやり思案したところ以前から自分でブログサイトを作りたかったことを思いだし難易度としても良さげだったので作ることにした。

## 使用した技術

- React(雛形はcreate-react-appで作成。webpackの導入は別のリポジトリで練習する)
- Firebase(Cloud Functions込みなので泣く泣く課金プランにした。と言っても料金は知れてるが)

さっすがサーバレス(Firebaseにおんぶにだっこ)アプリケーション

## 実際にmBaas(Firebase)を使ってみての感想

本当に便利。

これに尽きる。

認証、ストレージ、DB、ホスティング、バッチ処理など全部コミコミなんだから、なんというか、サーバサイド出身の自分としては

> 今まで僕がRailsでやっていたことは一体・・・

と思うくらいには衝撃を受けた。

## このサイトで実装したもの

#### 管理者としてのログイン機能

記事は管理者である自分しか操作出来ないようにするのはマストなわけで。

ここら辺はFirestoreとセキュリティルールの入門としては良い勉強になった。

参考にしたのはここら辺のサイト

https://firebase.google.com/docs/auth/admin/custom-claims

https://qiita.com/zaburo/items/cd078d768bd9fd239bf4

https://flattsecurity.hatenablog.com/entry/2020/04/10/122834

https://lnly.hatenablog.com/entry/2019/01/25/012744

どうやってユーザの権限管理をするのかというと、流れとしては

1. adminUsersにドキュメントが作成された時Cloud Functionsでそのアカウントにfirebase-adminを使って`admin: true`みたいなフラグを追加するような関数を作成してデプロイする

2. ログインが成功した後に`user.getIdTokenResult`の戻り値の`claims.admin`がtrueがどうかチェック

みたいな感じ。

本当はコードを載せたかったけどまだコードのシンタックスハイライトがついていないのでそのうち追記します。

先ほど紹介したサイトに全部載ってるのでそっちを参照した方が早いです笑

#### 記事の作成・編集・削除

Firestoreを触ったのが今回が本当に初めてだったので手探り状態でした。

まだシンプルなCRUDしか実現出来ていないのでこれからn対nのリレーションみたいなやつも実装していけたらと思っています。

## 最後に

とりあえずFirebaseの全体感というか

> こんな感じでセキュリティルール設定してFirestoreの設計してデプロイするんだ〜

というのを体験できたので収穫としては上々ではないかと思いました。

明日からもガンガン触っていきます。

## 追記

管理者としてのログイン部分のコードです！

シンタックスハイライトついて良かった！

```js
firebase
  .auth()
  .signInWithEmailAndPassword(email, password)
  .then(async (result) => {
    const { user } = result;
    if (user) {
      user.getIdTokenResult(true).then((r) => {
        if (r.claims.admin) {
          props.history.push("/");
          alert("管理者としてログインしました");
        }
      });
    }
  })
  .catch((error) => {
    alert(error);
  });
```