見出し画像

ポートフォリオ作成裏話

こんにちは、basyou(@bayoukajiki)です。
今回は私が作成したポートフォリオについて書いていきます。

こちらの記事はポートフォリオリポジトリのREADMEにも記事リンクを貼っているので、採用担当者の方、つまり私の本名を知っている方も読んでいただいているかもしれません。
一応断りを入れておくと、こっちでは「basyou」というハンドネームで活動しています。(笑)

さて、当記事の構成は以下の通りです。
ポートフォリオを日々アップデートしているので、「暫定」という言葉が頭につきますが...。

・作成したポートフォリオ
・使用した技術
・技術選定の話
・参考にしたサイト/教材
・苦労したこと
・ポートフォリオの弱点/不安に感じていること
・ポートフォリオ作成の他にやったこと
・今後について

ではよろしくお願いします。


## 作成したポートフォリオ

作成したポートフォリオは「MyContents!」といいます。
役に立ったリンクを簡単に共有できたらいいなと考え作成しました。

(noteだとOGP画像が表示されないみたいです...)

追記:

現在S3を停止しているため、ユーザーアバターを設定しても表示されません


### 使い方

スクリーンショット 2020-10-27 17.09.14

共有したいリンクをコピペして投稿します。

スクリーンショット 2020-10-27 17.10.15

すると、バックエンド側でURLからOGP情報を取得し、それをフロント側で良い感じのリンクカードに整形します。
リンク右下の▽をクリックすると、そのリンクの概要が表示されます。

ちなみにレスポンシブ対応です。

レスポン

ゲストログイン機能を実装していますので、気軽に触ってみてください。


## 使用した技術

使用した技術は以下の通りです。

・Nuxt.js
・Vuetify
・Ruby on Rails(APIモード)
・Rspec
・Docker/docker-compose
・Firebase
・Heroku
・GitHub-flow
・Atomic Design​

今回はフロントエンドとバックエンドを分離して開発してみたいという考えを軸に使用技術を選定しました。

今や未経験転職を目指す人達が当たり前の様に盛り込んでいるであろう「Circle CI 」や「AWS」は現段階では組み込んでいません。
ひと段落ついたら組み込んでいく予定です。


## 技術選定の話

上記の使用技術をなぜ選定したか書いていきます。
記事の構成上、順序が上記と異なりますがご了承ください。


### Ruby on Rails

元々Ruby on Railsを中心に学習していたため採用しました。
そもそもRailsを学習していた理由としては、Railsチュートリアルを始め日本語の教材が豊富であり、挫折しにくいと判断したからです。

技術選定の話なので、他フレームワークと比較した上で結論を出すべきだと思いますが、比較できるほど他フレームワークについての心得がないので学習のしやすさを優先しました。

APIモードで開発した理由は以下の通りです。

・SPAのアプリケーションを作ってみたかったから
・APIの理解を深めたかったから
・バックエンドとフロントエンドを分離して開発したかったから


### Nuxt.js

フロントエンドにはNuxt.jsのSPAモードを採用しました。
元々Vue.jsを学んでおり、VueCLIにてフロントエンドを構築しようと考えていたのですが、偶然Nuxt.jsという存在を知り、ドキュメントを読んでみたら割と分かりやすかったのでそのまま採用に至りました。

JavaScriptフレームワークとしてVue.jsを採用した理由は、Railsと同様に学習しやすいと判断したからです。
実際、HTMLライクで書けるというのは学習コストの面で非常に助かっています。
個人的にTypeScriptやReact.jsも学んでみたいのですが、現在はVue.jsに専念することにしています。

最後にSSRモードではなくSPAモードを採用した理由です。
先述した「SPAのアプリケーションを作ってみたかったから」という理由に加え、参考にしていたサイトや教材の関係上、並びにデプロイ周りに不安があったからというのも判断材料になりました。

アグレッシブさが足りないと思われるかもしれませんが、始めてNuxt.jsを触ることになるので比較的デプロイが簡単なSPAモードを使用し、より確実にリリースできる方法を取りました。


## Vuetify

CSSフレームワークとしてVuetifyを採用しました。
フロントエンド開発の時間短縮ができると判断したのが最たる理由になります。(本当はフルスクラッチで書きたかったのですが、今回のポートフォリオの趣旨とずれるので断念)

またドキュメントの豊富さ、コンポーネントの豊富さも魅力的に感じたことも理由の1つです。

Vuetifyが提供するグリットシステムのおかげで簡単に規則性のあるUIを作成することができました。
グリットシステムだけ採用し、他はフルスクラッチで書いてみるというのもおもしろいかもしれません。(いずれやってみたい)


### Rspec

テストフレームワークにはRspecを採用しました。
現場において多く導入されているという点、参考先の豊富さが採用の決め手です。


### Docker/docker-compose

開発環境の構築にはDockerを採用しました。
Rspecと同様に現場において多く導入されている点、自分の経験から導入するべきだと判断しました。

自分の経験というのは、過去に他のOSを使用される方と共同開発をした経験です。


### Firebase

ログイン認証とフロントエンドのデプロイにはFirebaseを採用しました。前々からFirebaseに触ってみたかったこと、分かりやすいドキュメントなどが判断材料となりました。

個人的にユーザーの削除が簡単にできる点が嬉しいです。

デプロイ先の候補にはHerokuやNetlifyがありましたが、使用サービスをコンパクトにまとめたかったのでログイン認証で元々使用しているFirebaseに決定しました。


### Heroku

バックエンドのデプロイにはHerokuを採用しました。
AWSを使用したかったのですがお金の都合上断念しました(他のポートフォリオでAWS無料枠を使用中)

Herokuの無料プランだと立ち上がりが遅いので、採用担当者の方にお見せする際、そこがボトルネックになっています。(現在はローディングアニメーションでごまかしています。)

ただ、デプロイの難易度は他と比べるとかなり簡単だと思いました。
正直デプロイ周りが苦手なのでありがたいです。

### GitHub-flow

プロジェクトの管理にはGitHub-flowを採用しました。
以前Git-flowを用いて開発したので、使ったことのないGitHub-flowを使用してみたかったのが理由です。

ごくたまにmasterブランチのまま開発を進めてしまうことがあり、頭を抱えました。


### Atomic Design​

Nuxt.jsのコンポーネント管理にはAtomic Designを採用しました。Atomic Designを採用しました。
コンポーネント管理に規則をもたらしてくれる導入してよかったです。

ただ、moleculesとorganismsの使い分けの基準がまだ明確になってしいません。


## 参考にしたサイト/教材

オンラインサロンなどは使用せず、書籍やUdemy、Google先生を使用して学習を進めてきました。

### Railsチュートリアル

「Rails 教材」ときた時に真っ先に候補としてあがる大人気教材だと思います。
ProgateでRailsコースをこなした後にこちらを挑むとレベルの寒暖差で風邪を引いてしまいます。
初めて挑んだ時は6章あたりで頭がクラクラし、11章でとどめを刺されました。

自分が学習していた時と違い、現在はテストフレームワークがminitestからRspecに変更されてるようです。

時間を見つけて再走したい教材です。

### Rails6実践ガイド

拡張機能編(なぜかURL埋め込めなかった...)

サービスオブジェクトとフォームオブジェクトについても書いてある貴重な教材です。
Railsチュートリアルより難しいですが読み応えがあります。


### 超Vue.js 2 完全パック

Vue.jsの基礎はこちらで学習しました。
消化途中でVue3がリリースされるという事態も発生しました。

網羅的にまとまっているので個人的にオススメです。


### Nuxt公式ドキュメント

日本語対応していて分かりやすいです。
自動ルーティングでつまづいた際時などに参考にしました。


### Vuetify公式ドキュメント

つい先ほどまで日本語ページがありましたがいつのまにか消えました。
使用例とコードが載っており、分かりやすいです。

Vuetifyに関しては公式ページを読んでおけば大丈夫だと思います。


### その他参考にしたサイト

私のポートフォリオ作成にあたってドンピシャな内容でした。
こういった記事は本当にありがたいです。

Udemyの他にこちらのサイトでVue.jsの基礎を学習しました。
Vuetifyの初歩的な使い方を取り扱った記事もあるので、これから開発されるという方に是非おすすめしたいです。

Dockerfileの記述方法はUdemyの他にこちらのサイトを参考にしました。
1つ1つ詳細に解説されているのでとても分かりやすいです。
人の心がわかる人とはこういう人のことを言うんだと感じました。


## 苦労したこと

続いてポートフォリオ作成の際に苦労してきたことを書いていきます。


###  RailsAPIを扱かった教材が少ない

とにかくRailsAPIを使用した教材が少ないことに苦労しました。
特にJSON周りはこれまで学習したことがなかったので、どのようにJSONを出力すればいいか自分で1から調べることになりました。

結果、Active Model Serializerというgemを導入し、JSONデータの整形を任せています。


###  頻出するN+1問題の対処

油断をすると大量のSQLが発行されてしまっていたので、その対応に追われました。
おかげでincludesメソッドの株が自分の中で急上昇しました。

Herokuによりただでさえ立ち上がりが遅いのに、立ち上がった後も遅く(重く)なってたまるかという思いで現在も対処中です。(Bulletを導入するべきかもしれません)


### 複数モデルの同時投稿・同時編集

複数のモデルを同時に投稿・編集したいと考えた時、おそらく初学者の方はaccepts_nested_attributes_forというメソッドに行きつくと思います。

実際に「Rails 複数モデル 投稿」と検索すると上記のメソッドを使用した記事がヒットします。

しかしどうやらこのメソッド、なにやら癖がありRailsの生みの親であるDHHも「消したい」と思っているらしいです。

この記事を読んだ瞬間にaccepts_nested_attributes_forメソッドを使用しないと決心しました。

どのようにして同時投稿・更新を実現するかと考えた結果、サービスオブジェクトを使用することにしました。
これは先ほど参考にした書籍にて挙げたRails6実践ガイドからアイデアを貰った形になります。

サービスオブジェクトを導入するにあたって以下のような記事も参考にしました。

(余談ですがサービスクラスとサービスオブジェクト、どっちが正しい呼び方なんでしょうか?)


### Nuxt.js/Vue.jsにおけるライフサイクルの理解

開発当初、隙あらば「Cannot read property '○○' of null」というエラーに遭遇しました。
ライフサイクルについての理解が足りない故に発生しました。
おそらく1番遭遇しているエラーです。

たまに下記記事のような罠に遭遇しました。

ライフサイクルについてはまだまだ学習中です。


### 技術選定

現在エンジニア転職を目指す業務未経験者の方達のポートフォリオのレベルがインフレしていると聞きます。

曰くDockerは当たり前。
曰くAWSは当たり前。
曰くCI/CDツールは当たり前。

彼らに引けを取りたくない思いもあり、これらの技術スタックを盛りこもうと考えていましたが、時間がかかりそうだったので、まずは職務経歴書に掲載できる状態に持っていくことにしました。

完成したポートフォリオを掲載した方がいいとの意見もありますが、それ以上に長期戦のリスクが高いと判断した結果です。

私の変なところで完璧主義な性格と相まって、自分の想定する100%の技術スタックから削っていくのは苦労しました。
しかし、毎日コミットすることで日に日に100%の状態に近づけるように努力しています。


##  ポートフォリオの弱点/不安に感じていること

自身のポートフォリオの弱点に関して書いている記事はあまり見当たらないので、そう言った意味では貴重な情報かもしれません。
挙げるとキリがないので一部を紹介します。

### スパゲッティコード/力技コード

ポートフォリオの弱点筆頭候補です。

特に力技で解決した箇所がいくつか点在します。
以下力技コードの例です。

・更新の際に既存レコードを一旦全削除
・v-ifによるCannot read propertyエラーの解決
・vuexが保持する状態(データ)の肥大化


### テストの強度不足

Rspecを学習中のため、どうしても「検証したい」よりも「書ける」を優先してしまいがちになります。

また、フロントエンドの側のテストフレームワーク(Jestなど)の知識が皆無なため、現在フロントエンド側のテストができていない状態にあります。


###  DBパフォーマンス(N+1問題の解決)

ある意味力技コードですが、例えばincludesメソッドを使用する際に以下のような記述をしています。

Model.includes({user: {avatar_attachment: :blob}}, :links, :likes, :tags)

N+1問題の解決方法における自分の引き出しがincludesメソッドしかないので、上記のようなコードになっているのですが、果たしてこれが良いのか悪いのか不安になります。


## ポートフォリオ作成の他にやったこと

技術選定を終えた後に、現在の転職市場において技術スタックが他者と比べ見劣りすることは明確だったので、差別化、開発の円滑化を図るためにドキュメントを残すことにしました。

また、初めての現場で自分が1番最初に何ができるかと考えた時、Webライターとしての経験を生かし「ドキュメントを書く」ことが自分にできることだと考えたのも判断材料の1つとなりました。(そもそもコードをかけないと意味がないかもしれませんが...)

そしてこちらが実際に書いた記事になります。(現在は公開を停止しています)

ドキュメントといっても堅苦しい文面ではなく、かなりカジュアルに書いています。
ちなみに初めて技術系の記事を書きました。(書くの難しい...)

開発と並行で記事を書いていたので、記事構成やその他諸々を詰め切れていない箇所もありますが、ぱっと読み返したときに過去の自分の意図が汲める内容に仕上げられたかなと思います。
ポートフォリオができ次第もっと分かりやすい記事に書き直すつもりです。

また、Qiitaにも記事を投稿しました。(現在削除済み)


## 今後について

現在も日々完成度向上のために毎日ポートフォリオをアップデートしています。
GitHubに草が生えていない日は苦戦してデフォルトブランチにコミットできていなかったり、書籍やUdemyで学習したりしている場合が多いです。

ポートフォリオのアップデートに伴って当記事の内容もアップデートしていく予定なので、今後ともよろしくお願いします。

ではこの辺で。


この記事が気に入ったらサポートをしてみませんか?