My-Memoria
転職用のポートフォリオとして画像投稿アプリを作成しました。
技術スタックはREADMEをご覧ください。
こちらには開発までの経緯や苦労したことを記述します。
自己紹介
昔からプログラミングに興味があり、たまにProgateでHTML,CSSを触りながら公務員として働いていました。
職場で業務改善用のツールを作り効率化を図る中で「自分でアプリを作って誰かに喜んでもらいたい」と思い始め、昔から興味のあったプログラミング
「誰かにサービスを使って喜んでもらいたい」という気持ちを叶えるを叶えるのにWeb系エンジニアがふさわしいと考え。
エンジニアは会社の業務とは別に継続的な自己学習キャッチアップが必要だと思い、働きながら本格的にプログラミング学習を進めることを選択し、画像投稿サービスの開発&リリースまで実行しました。
現在、転職活動中の28歳です。
ポートフォリオの開発期間
2024年３月現在の形になるまで4ヶ月程度かかりました。
本格的なプログラミング学習自体が初だったので、下記のような流れで学習と開発を行ってきました。
７月
Progateを本格的に開始。HTML,CSS,JavaScript,Rubyのコースを一周。もの足りなくなりスクールの受講を決意。
8月〜9月
高いコストをかけて手厚いサポートを受けても成長に繋がらないと思い、コスト低いけど「自分で調べたり開発する力がつく」と評判のスクールを受講。Ruby on Railsをメインに学ぶ。
10月〜12月
スクールで学んだ技術をアウトプットする形でポートフォリオを作成。一旦の完成後、転職活動やコードテストの対策などに時間をかける。
１２中旬〜１月
祖父が亡くなり帰省したりで、人生観や転職の目的・軸を見直すことに集中。エージェントを通して応募してみた結果、書類選考でほぼ落選しポートフォリオの技術力向上が必要だと感じる。
１月中旬〜2月
ポートフォリオの向上を目的に開発を再開、スクールでは学んでいなかったDockerやGithub Actionsなどの技術を取り入れる。
現在は実務で主流となっているReact×TypeScriptを使用したフロントエンドの実装やAWS（VPC, ECS, RDS Aurora, S3など）を用いたインフラ構築を視野に入れ、学習と開発を継続中。
技術選定理由
開発環境
Docker・Docker-compose
- 環境構築が短時間で行える
- コンテナのため軽量に運用できる
- チーム開発時に同一の開発環境を作れるため、Web系企業でよく使われているため
フロントエンド
Bootstrap
- グリッドシステムで簡単にレスポンシブ対応を実装できるため
jQuery
- コードを短くしやすく、作業時間の短縮と可読性を向上できるため
バックエンド
Ruby・Ruby on Rails
- Web系のスタートアップでよく使用されており、素早く開発できる
- 日本語の情報リソースが多く、開発中のエラーにも素早く対応できると考えたため
インフラ
Heroku
- インフラ構築に時間を取られず、開発に集中できるため
- 継続的なサービス運用を考えるとランニングコストを抑えられるため
AWSは実務で必要なスキルであるため、現在学習しながら、別のアプリをAWSにデプロイすることを試みています。
作成時に苦労したポイント
jsonとHTML表示の両立
Ajaxを用いた非同期通信でコメントを表示する機能の開発時、JSONレスポンスとHTML表示の両立に苦労しました。
なぜかHTMLではなく配列が画面全体に表示されてしまう状態に直面。解決の糸口がなく何日も頭を悩ませましたが、最終的に自分の技術に対する理解が足りていないと自覚し、複数のリソースを参照して解決できました。
Bootstrapの動作不良
レスポンシブ表示のために導入したBoostrapが本番環境で動作せず、原因を調べているうちに開発環境でも動作しなくなり解決に苦労しました。
公式ドキュメントを読み、本番環境はスタイルシートの記述漏れ、開発環境はアセットを作成してしまったことが原因だと発覚し解決できました。
erb2hamlによるデプロイ失敗
Herokuへのデプロイ時、ビルド中にerb2hamlのgemが見つからずビルド成功まで苦労しました。依存関係の再インストールを実行したり、本番環境で読み込まれるようにgemの配置場所を変えても成功しませんでしたが、一度erb2hamlの必要性を考え直し、削除することで解決できました。
Docker導入後のデプロイ
プログラミングスクールではDockerの学習がなかったため、ポートフォリオに組み込む際は実装に時間がかかりました。Dockerを使用している時はデプロイ時もcontainerでビルドされるべきと思い込み苦戦しましたが、Herokuがそもそもcontainerによるビルドを推奨していないと気付き解決できました。
メール送信のために独自ドメインを実装
スクールでメール送信機能として紹介されたSendGridが個人利用できず、別の方法を模索。
メール送信のコードを書くだけでなく、ドメインの取得やDNSレコードの設定などインフラの仕組み自体を理解するまで時間がかかりました。
実装までに公式ドキュメントやQiitaを読んで一つずつ理解していきました。
作成から学んだこと
問題解決の際は前提となる知識を調べ、一つ一つ仕組みを理解しながら自分の頭で考えることが重要だと学びました。ChatGPTにエラー文を解読させ開発していましたが、ポートフォリオの作成通して「AIは明示されていないエラーの解消には弱い」と実感しました。
現在は、バグやエラーの解消は「①AIに原因を推測させる②自分で周辺知識の公式ドキュメントやQiita/Zennを参照③解決案を一つずつ検証」という流れで行なっていくのが一番効率的と考え、実践しています。
ただし、チーム開発に携わる際は一人で考えすぎてもいけないと考えています。 時間を大きく浪費するかもしれないし、もっと優れた解決方法に気づかないかもしれないからです。
①②の工程を素早く済ませつつ、先輩方と「解決の方向性は合ってそうか、他に優れた方法はないか」と意見交換をしながら③に取り組みたいです。 未経験の自分が先輩方の足を引っ張ってはいけないですが、開発を円滑に進めるためのコミュニケーションは積極的を行う必要があると考えています。
追加したい技術
- React×TypeScriptによるフロントエンドの実装
- AWSによるインフラ構築
最近主流になりつつある上記の技術を学び、アプリに実装したいです。
今後の展望
一人で何日もエラーと向き合った経験を活かし、実務でもエラーこそ学びのチャンスと認識して粘り強く開発に着手したいです。
何日もエラーと向き合うのは本当に辛くて、何度も「永遠に完成しないんじゃないか」「自分には無理だったのか」と思うこともありました。しかし、一つずつ紐解いていくうちにエラーは必ず解消できるという実感を得られ、パズルを解いた達成感と大きく成長できた喜びも感じられました。
エンジニアとして働く際にも、まず自分自身の知識を磨き続け「エラーは学びのチャンス！」と捉えて着実に解決していきたいです。
チーム開発について
今回は個人開発だったので好き勝手にブランチを作成したりコミットしていましたが、今後は実務でのチーム開発を見据えて学習を続けます。コミットメッセージやブランチの規則性・正確性を意識したり、可読性の高いコードで開発することを意識して開発に取り組みたいと考えています。
直近では、チーム開発の現場で使われているというDockerの導入を実行しました。
今後もチーム開発への参加に向けたキャッチアップを継続して実力を高め、より優れた手法について積極的な意見交換を行いながらチームに貢献できるエンジニアを目指して学習します。
終わりに
今回、初めてゼロからアプリケーションを開発する中で、非常に多くの学びがありました。
サービスを開発する中で何日もエラーが解決できなくて、それでも調べながらトライ＆エラーを繰り返し、やっとプログラムが動いたときの快感は強烈でした。
現在、転職活動中ですが、1日でも早く実務をこなせるエンジニアとなるために、プログラミングを楽しみながら継続して学習していきます。
長文となりましたが、最後まで記事を読んで頂きありがとうございました。