どうもこんにちは。大平です。
Twitterを観測していると、「技術者はポートフォリオ組んだほうが絶対に良いよ！」とよく言われます。
考えてみると、私も動かせるシステムでかつソースコードを公開している、ポートフォリオと呼べるものがないな、と思ったので７月を使って作成しました。
Hobbycart
ソースコードはgithubにて公開中です
簡単なECサイトを模したシステムです。管理画面から商品の追加、フロント画面からは商品を検索したり、コメントをつけたり、「いいね！」をすることができます。
購入ボタンを押すと「購入ログ」に入ります。（このシステムはあくまでポートフォリオなので、実際の決済が発生するわけではありません）
また、あくまでポートフォリオサイトですので、管理画面もすべて開放しており、見られるようになっています。
ログインはoauth認証を使っており、Twitterアカウントからアカウントを作成してログインすることができます。
インフラ
インフラはドキュメントを読みつつ試行錯誤の末、Google App Engineを選択しました。
当初はGoogle Kubenetes Engineを予定していたのですが、覚えることが多く公開まで時間がかかると判断して途中でGAEに切り替えました(´・ω・｀)
ちなみに、PaaS間の移植性の観点でHerokuも試してみましたが、「Heroku⇔GAEを設定一行書き換えるだけで移せる」ような感じではないので、Railsを動かすPaaS選定は割と初期の決断コストの大きい事柄なのかなと思っています。
ちなみにGAE、なんかデプロイにすごい時間（10分くらい）かかります(´・ω・｀)
アーキテクチャ
アプリケーションサーバはRuby on Rails 5.2.0。
DBはローカルではdocker mysql,本番ではCloud SQLを使用しています。
ファイルストレージは、ローカルでは一時ファイル、本番ではCloudStorageを使っております。
やや余談ですが、AWSとその役割を比較するならば、RDS⇔CloudSQL、S3⇔CloudStorageといった感覚です。
実装概要
実装の詳細はソースコードを見ていただくとして、
認証部分は枠組みをSorceryというgemを使って実装しています。Deviseと一長一短ですが、こちらのほうが柔軟性が高く、Wayをあまり押し付けてこない利点があります。あと前職で使ってました。
パンくず部分はGretelというgemを使って実装しています。パンくずの設定がDSLで簡単にかけるgemです。
検索フォームに関してはRansackというgemを使って実装。かゆいところに手が届く検索ライブラリで、ElasticSearch使わずにRDBで頑張る人は導入を検討すべきライブラリだと思っています。
ページングに関しては定番Kaminariを導入。
フロントは基本的にSSRで、どうしてもフロントでの動きが必要なものだけVueで切り出す、という方針で進めていました。
書く過程でVueの基本的な使い方のおさらいができたと思いますが、親子構造の構成をミスったことを実装中に発覚するなど、まだまだ課題は多いVue実装です。次回プロジェクトではVuexにチャレンジしていきます。
さて、このプロジェクトではCSSがほとんど書かれていません。
Bootstrapのクラス付与だけで「それっぽいUI」を作ることができてしまうからですね。
rails g scaffoldで作成した管理画面でも、Bootstrapのクラスを与えてあげるだけでなかなか良い感じになってくれたりします。
これは高速な仮説検証が必要となるPoCフェーズにおいて非常に良いと思っています。作り込みせずBootstrapの枠の中で、それなりによい画面ができるのですから。
テストに関しては定番の
・rspec-rails
・factory_bot_rails
・shouda-matchers
・faker
・rails-controller-testing
を追加し、rspecでテストコードを書いています。正直あまり書けていませんが…
公開するときに気をつけるべきこと
AWSなどのアクセスキー・シークレットキーがソースコード中に紛れ込んでないかを入念に確認してください。
これを怠ると、アクセスキーが流出してあなたのEC2インスタンスで無限にビットコインがマイニングされる可能性があります。
これらの情報はdotenvなどを用いて環境変数として入れ込む設計にし、コミットには含めないことを徹底しましょう。
ただわたしも一回やらかしてしまい、フォロワーさんから指摘を受け即座にキーのRegenerate、修正・再デプロイをするはめになってしまいました。（ご指摘いただいた方本当にありがとうございます！！）
githubにもリンクを知っている人限定の限定公開とかあればいいんですけどね。
まとめ
正直、ポートフォリオ・ソースコード公開までできる人は少ないと思う
これを採用要件に入れてしまうとほとんどのエンジニアが要件に適さなくなっちゃうんじゃないでしょうか。
前述したように、ソースコードの公開はセキュリティリスクと隣合わせの危険な行為なので、未経験者にこれを課すのは過酷すぎる印象を受けます。
逆に言えばポートフォリオ作ってたらどんな出来であれノールック採用して問題ないんじゃないでしょうか。
そもそもポートフォリオのテーマが事業ニーズあったら就職のためじゃなくてそのまま起業しちゃえばいいですし。
しかし、全体としてポートフォリオの作成は本人の学習的な意味でも非常に意味があると思うので、ソースコード公開まではできなくても作ってみるといろいろと捗る気がしてきました。（技術検証をしたいときのSandboxアプリとしても使える！）
それでは、今日はこの辺で！
【PR】 Ruby on Railsを学んで自社開発エンジニアになりたいなら
