【新卒エンジニア】PJTで得られた学びとURIについて
はじまして。スーパーソフトウエア東京オフィス 新入社員の清水です。
本記事では、僕がエンジニアとして働き始めて、4ヶ月で得た学びを少し書いてみようと思います。
はじめに
本記事では、以下の２つのテーマについてまとめます。
1. 実際のプロジェクトで得られた学び
（基本情報の勉強や、簡単なアプリを作ってみるなど自己学習だけでは得られなかったこと、知っていても具体的にどんなものか想像できていなかったとこと、先輩エンジニアに教えていただいたtipsなど）
2. URI(Uniform Resource Identifier)
1. 実際のプロジェクトで得られた学び
ここでは、僕がプロジェクトに参加して4ヶ月で得た学びを20個ほど箇条書きで紹介します。（抜け漏れ重複などがあると思いますがご了承ください）
なにが正かを考える（どう在るべきか、Goalの確認）
原因の切り分け
処理(ソースコード)のミスか、データのミスかを判断する
ショートカットキーの活用（⌘はwindowsの場合だとcontrol）
例えば、vscodeでの⌘ F、 ⌘ shift F、 ⌘ P。ターミナルでのTab補完など
デバッグ
Xdebug、ブラウザのデベロッパーツール、Postmanなどを活用
エラーが起きた際に疑うべきではないファイルがある（例えば、`.core`や`.vendor` など）
一般論の事象かプロジェクト固有の事象かを判断する
一般論の事象であれば、ネットでググる
固有の事象であれば、PJTのドキュメントを読む、チームメンバーに聞くなどする
コードの読み方
すべてのコードを真面目に読まなくても、既存のコードはある程度信頼して、変数名や関数名から流れを理解する
エラーを改修する際などに、該当コードを見つける方法
開発者ツール(F12)のポインタを使う
フロントの要素や変数名で探す
どの関数が呼ばれているかをみる
ページ読み込み時（constructer）
ボタン押下時（webではこれが多い）
URIはコントローラー名/アクション名(例えば、item/condition)
セキュリティ対策
エスケープ、エンコード、XSS、CSRF
セッション、クッキー、キャッシュ、セッションストレージ、ローカルストレージ
Git/GitHub
チケット
backolg（チケット管理）
URIのバリデーション
正規表現を用いた検証。スキームの有無、大文字小文字の区別しない、マルチバイト文字の取り扱い、RFC(Request For Comment)の準拠(https://triple-underscore.github.io/rfc-others/RFC3986-ja.html#section-3.1)
マイクロサービスアーキテクチャ
Web版、スマホ版、アプリ版をコンテナごとに分離する
WebAPI
サービスクラスへの切り分け → 単体テストの実施判断、観点
デグレとリグレッション
XMLHttpRequest
2. URI(Uniform Resource Identifier)
ここから、URIについて掘り下げてみます。 URIについて掘り下げようと思った理由としては、以下があります。
URIはWeb技術の根幹ともいえる重要な要素
HTTP通信を通じてリソースをやり取りする際、URIは欠かせない存在であるセキュリティの観点で重要性が高い
URIはユーザーが簡単に編集できるため、セキュアなシステムを構築するためにはURIの適切なバリデーションが必要になる開発中にURIの複雑さと煩わしさを感じた
実際にプロジェクトでURIのバリデーションを実装した際、URIは様々な形をとる可能性があるので、煩わしさを感じた
これらを踏まえ、簡単にまとめたいと思います。
URIとは？
URI（Uniform Resource Identifier）は、リソースを一意に識別するための文字列です。
URI = URL(位置指定子) とURN(名前)の両方を含む概念
（Web開発においては、ほとんどの場合URLが用いられるため、Webの文脈では「URI と言われたら、URLのことね」と考えていいと思います）
URI, URL, URNの具体例
例えば、家の中にあるタオルの位置と名前の両方を識別するシステムがあったとすると、URIは次なようなものになります（家の中のタオル1）
URI: http://home.example.com/towels/1#urn:home:towel:1
これは、タオル1の位置（URL部分）とその名前（URN部分）を組み合わせたもの
URL: http://home.example.com/towels/1
タオル1の具体的な位置を示す
URN: urn:home:towel:1
タオル1の名前
WebにおけるURIの役割
Googleで何かを検索する際に、DNS(Domain Name System)という仕組みによって、ドメイン名がIPアドレスに変換され、インターネット上の見たい情報（一意に識別されたリソース(URI)）にアクセスできることは知っている方が多いと思います。
URIはウェブサイトやAPIのエンドポイント、そしてAWSのようなクラウドサービスにアクセスする際などにも使われる、Web技術の根幹ともいえる存在です。
例えば、AWSのストレージサービスであるAmazon S3にアクセスする際なんかにも、以下のような形式のURIが使われたりしています。
https://bucket-name.s3.amazonaws.com/key
URIの構成要素
URIは以下の要素で構成されています。
※詳しくはRFC(Request For Comment)を参照↓
https://triple-underscore.github.io/rfc-others/RFC3986-ja.html#section-3.1
スキーム：リソースにアクセスするためのプロトコル
例: http、https
オーソリティ：サーバーのホスト名やポート番号を示す部分
ホスト名: サーバーのドメイン名
例: www.example.com
パス：サーバー内のリソースの位置
例: /path/to/resource
クエリ：追加のパラメータ
例: ?id=123&type=pdf
フラグメント：リソース内の特定部分
例: #section2
URIバリデーションの重要性と難しさ
実際にプロジェクトでURIのバリデーションを実装する機会があり、その際に僕は難しいなと感じたのですが、以下のような理由があります。
URIは状況によって様々な形をとる
セキュリティの観点から厳密な仕様、バリデーションが要求される（SQLインジェクションやXSSなどの脅威から守る）
たとえば、クエリパラメータにはアプリ固有の無数のバリエーションがあります。スキームやホストの部分も、単に「http」や「https」で始まっていれば良いわけではなく、正しいフォーマットであることを確認する必要があります。
また、URIに含まれる特殊文字やエンコーディングの処理も重要になります。これらを適切に扱わないと、ユーザーから送信されたデータが正しく処理されない可能性があります。例えば、スペースやアンパサンド（&）などの特殊文字は、%エンコーディングされてURIに含まれますが、これらを正確にデコードしなければ、誤ったリソースにアクセスしてしまうかもしれません。
ここまでURIについて簡単にまとめてみましたが、
URIの難しさの克服方法としては、僕は「徐々に慣れていく」という姿勢でいようと思います。RFCを読んでみてもURIを構成する要素は多いので、一朝一夕に完璧なURIバリデーションを設計するのは困難だな感じています。
おわりに
URIはWeb技術の根幹を支える重要な要素なので、理解を深めてより適切な扱いができるようになりたいと思います。
本記事を通じて、僕が実際のプロジェクトで得た学びを共有させていただきました。また、拙い説明になりましたが、URIに対する理解が少しでも深まっていれば幸いです。
次回はAWSでデプロイした個人アプリについての記事でお会いしましょう！
それでは良い１日を！
▼採用情報
▼新卒情報はWantedlyで
この記事が気に入ったらサポートをしてみませんか？