Ruby： オブジェクト指向設計について
Qiitaに書きました！
オブジェクト指向設計について学んでます
初日はもう無理だと思ってましたが
少しずつ少しずつ理解してきて確実に
昨日の自分より進化してる感があって楽しいです！！
比べるのは他人ではなく、昨日の自分です！
毎日学習怠らず、積み上げていきます！
Web技術の基本：Webアプリケーション開発で必要な知識を私なりにまとめてみました！
おはようございます、こんにちは、こんばんは！
閲覧ありがとうございます！
Webの基礎を勉強しました。
これらの意味を上から順に自分なりの言葉でまとめてみました！
リクエスト
レスポンス
ポート番号
ステートフル
ステートレス
Cookie＆session
全体として少し長いのですが
分かりやすい感じでまとめて見ましたのでサラーっと目を通していただけると幸いです。
こちらは今回参考にした教材です
『プロになるためのWeb技術入門』――なぜ，あなたはWebシステムを開発できないのか
目次
プロトコル
プロトコルとは、コンピュータやネットワーク機器間の通信ルールであり
ウェブ上でHTMLや画像などの定められた通信プロトコルがHTTPと言います。
もう一つあってTCP/IPと呼ばれるプロコトルがあり
IPアドレス(住所)にむかってクライアントに情報を届ける役割があります。
現実的に言うと郵便配達の位置付けによく似ています
まとめると：コンピュータやネットワーク機器間の通信,情報の伝達方法のこと
リクエスト
一言で言うと
Webアプリ使うときやHPを見るときにWebクライアントからWebサーバーに通信すること。
さらに深掘りすると
例としてGETとPOST２通りのHTTPリクエストあり
HTTP通信GETメソッドは共有されてもいいページ頂戴とお願いする時。
HTTP通信のPOSTメソッドは個人情報などの機密性の高いリクエストで使用例が
フォーム入力やログイン情報をした時に使います。
分かりやすく言えば
GETメソッドは「共有されても大丈夫な情報をお願い！」というリクエストで
POSTメソッドは「機密性の高い情報を送るので、安全に処理して！」というリクエストになります。
レスポンス
一言で言うとレスポンスはWebサーバーからWebクライアントに通信を送ること。
リクエストした際に行われる行動です。
さらに深掘りするとHTTPレスポンスにて、ステータス・コードがあり200番だとリクエスト成功となる
300番台はURLの一時的な移動。
400番台はクライアント側で起きたエラーリクエスト失敗を示す。
401のユーザー認証失敗
403アクセス権限なし
404良くあるお探しのページはありませんで出てくるエラーです。
500番台はサーバーエラーサーバー側のエラーでプログラム実行によってエラーが発生します。
開発者が修正しなければ治らないエラーリクエストの失敗を示す。
以下をまとめると
- 200番台のステータスコードは、リクエストが成功したことを示す。例: 200 OK
- 300番台のステータスコードは、リダイレクトを示す。クライアントは、追加のアクションを行う必要がある。例）URLの一時的な移動がある場合に起きる。
- 400番台のステータスコードは、クライアント側で起きたエラーを示し、リクエストが失敗したことを示す。
- 401 Unauthorized: 認証が必要
- 403 Forbidden: 閲覧禁止、アクセス権限がない
- 404 Not Found: ページが見つからない（URLが間違っていることが多い）
- 500番台のステータスコードは、サーバー側で発生したエラーを示し、開発者が修正しなければリクエストが成功しないことを示す。例: 500 Internal Server Error
ポート番号
ポート番号は、通信を行うアプリケーションやサービスが特定のポートを待ち受けして、
送られてくるパケットを正しく処理できるようにするために使われます。
ポートは、通信を行う際の「港」のような役割を果たしている
TCP/IPによって情報を受け取るアプリケーションは必ず『待ち受けポート』を
決めて情報を持つ。ポートは0~65,535までの数字で表され、
同じポートを複数のアプリケーションは使用することはできない！
例えば：マンションの部屋番で考えると、住んでる人(アプリケーション)の部屋に
知らない人(違うアプリケーション)がその部屋に入るのはおかしいですよね？
なので別々のポート番号にしましょうと言うことです
ただしよく使われるポート番号が別々のポート番号にしてしまうと、
HTTPプロコトルの通信もバラバラで不便です。
URLで省略できているポート番号も指定しなければなりません。
そこでよく使われるプロコトルについてはポート番号を取り決めておくことになっています。
代表的なプロコトルで使用されるポートは『ウェル・ノウン・ポート』と呼ばれています
例えば↓
| ポート番号 | 用途 |
|---|---|
| 22 | SSH(暗号化された通信) |
| 80 | HTTP通信 |
| 443 | HTTPS（セキュアな暗号化されたHTTP） |
これらは必ず統一させます。
ステートレス
HTTPのみではログイン状態を維持できない（覚えられない）
HTTPでは１回のリクエストとレスポンスで処理が完結するため、
過去のリクエストに関する状態を持たない。
そのためHTTPは状態を持たないプロトコルで
このことをステートレスプロトコルといいます。
分かりやすくいうと：１歩歩くと忘れる感じです、鶏🐓の進化版ですね。
ステートフル
ステートレスの逆として
前回のリクエストの結果を覚えていてそれを踏まえて次のリクエストを実行している
リクエストに伴って状態が変化し、状態を持つプロトコルのことを
ステートフルプロコトルと呼ばれています。
ステートレスとステートフルの違いについて分かりやすく解説
ステートレスの例
自動販売機では、お客さんが飲み物を購入するたびに、
お金を入れてボタンを押す必要があります。
自動販売機は、その人個人の過去の購入履歴を記憶していません。
お客さんが何度も同じ飲み物を購入する場合でも、毎回同じ商品のボタンを押すことになります。
これがステートレスの例です。
ステートフルの例
一方、高級カフェ店では、常連さんが飲み物や食事を注文する際に、
店員が常連さんの過去の注文履歴や好みを記録していることにします。
次回以降、常連さんがそのカフェを訪れたときに、『いつものセットで』というと
店員は『かしこまりました』とそれだけで注文を完了できます。
これが前回のリクエスト(注文履歴)を踏まえているステートフルの例です。
ではこれらをどのようにして記録しているのかは
次のCookieと言う仕組みがあるので説明していきます。
Cookie
Webブラウザに状態を持たせる仕組みそれがCookieという仕組みです！
Cookieの仕組みは、WebサーバーからWebブラウザ(クライアント)へHTTPレスポンスのヘッダを利用し情報を送る
この情報は『キー＝値』の組み合わせでこれをCookieと呼びます
WebサーバーからCookie受け取ったWebブラウザ(クライアント)は、次回同じWebサーバーにアクセスする際に
受け取ったCookieをそのままHTTPリクエストヘッダに入れて送る。
Webアプリケーション側ではリクエストヘッダに
入っているCookieを調べることで
アクセスして来た相手がどんな相手なのかを知ることができます。
つまりCookieのおかげでステートフルが実現できている。
おまけ↓
Cookieの名前の由来：
お菓子の「フォーチュンクッキー」に由来しています。
フォーチュンクッキーは、クッキーの中に紙片が入っており、
紙片には短いメッセージや予言が書かれています。
サーバーからブラウザ(クライアント)へ送られる小さな情報（ユーザー認証や設定の保存など）を含んでいます。
このため、フォーチュンクッキーというアイデアに基づいて名付けられたとされているらしいです！
Webブラウザ(クライアント)のCookieは、内部に情報を持っている点とフォーチュンクッキーの中にあるメッセージと似てますね！
別の説として
マジック・クッキーとも関係があるらしいですが私は調べてないので分かりません。
気になる方は調べて見てください！意外と面白いですよ。
セッション(Session)
だだし今のままでは、問題があります。 Cookieの中身は個人情報が丸見えです。
ちょっと知識がある人ならば簡単にのぞけてしまいます。(PC上にtext fileとして保存されている)
もし個人情報の中にユーザー名やパスワード、クレジットカード番号が丸見えで見えていたら、、
と考えるだけで恐ろしいですね。
なりすましで勝手に買い物されたりと被害につながりかねません。
銀行口座が見れるアプリやECサイトなどは特に注意が必要ですね。
こんなセキュリティ上非常に大きな問題のあるCookieですが、
ある仕組みとセットにすることでこのデメリットは解消されます。
それが『セッション』と呼ばれる仕組みです。
セッション(Session)とは何か、
ログインします→お買い物で書籍を買います→注文確認画面が出て→ログアウト
このような一連のHTTPリクエストの処理の流れを『セッション(Session)』と言います。
じゃあこのセッションの状態をどこで保持するのか？
それはWebサーバーで管理します。
では、どのようにしてPC上の情報をWebサーバーに紐付けるのでしょうか？
その役割を果たすのが「セッションID（SessionID）」です。
セッションIDというのは数字です。分かりやすく言えば管理番号です。
管理番号で個人情報を管理することで、一意であり重複することがないので、
同姓同名な人いてもサーバー上では番号なので、迷わず管理して的確に今までの情報を割り当てます
このような重複しない一意なものを『ユニーク(unique)』と言います。
ここまでお話しすると勘の言い方はお気づきだと思いますが、
CookieにセッションIDだけ保管していれば個人情報丸見えの状態より安全性が高いことがわかります。
ただし！簡単なセッションID(数字のみ)だと
セッションハイジャックされ結局なりすましされてしまいます。
セッションIDは推測できないような長くて複雑なものにしましょう
例えばこんな感じ：AEIGAHIHVOWHEAHGREAOI12R442GVFGOGE
それでは、Cookieの一連の流れをまとめて見ました。
Webクライアント側が、個人情報を入力(ログイン)→HTTPリクエストされた個人情報をサーバー側でセッションID発行し個人情報を記録しCookieにセッションIDを格納して返す→ またクライアントがセッションIDを格納したCookieをサーバーに渡します→サーバーがそのセッションIDから個人情報を特定しこの人は今この状態だと認識することができます。
ステートフルな状態を保つためにはこの一連の流れが行われています！
ここまでの知識を踏まえた上で
それぞれのステートを使う場面について軽くご紹介します。
ステートフルとステートレスの使い分け
ステートレスの場合
静的コンテンツ(HTML)や情報を記憶しなくていい
ただ単にページ遷移するときに使われます。
メリットは、シンプルかつ軽いとこのような点がありますので全てステートフルで
いいというわけでは無いですね。
ステートフルの場合
ユーザーのログイン状態を保持するような場合や、
複数のリクエストにわたって状態を維持する必要がある場合は、
ステートフルが適切です。
複数のリクエストに関して状態の維持についてを分かりやすく深掘りしますと
ECサイトがあります。
買いたいものをカートに入れます→確認画面に入ります→購入ボタンを押します→購入ありがとうございました画面が出ます。 このようにいっぱいページ遷移する場合で、お客さんと買った物の情報を覚えてなきゃいけないですよね？
もしステートレスですと、
カートに入れて確認画面に入ると
買ったお客さんを忘れカートの中身が無いという
クソアプリができてしまいます。
無限ループです一向にお買い物できませんと、
こういう場合にステートフルを使います。
デメリットもあります。
サーバーの負荷が増える、開発や、メンテナンスのコストが増えるetc...
なのでうまくステートレスとステートフルを使い分けましょう！
正直なとこフレームワーク使いますと勝手に使い分けてくれてる気がしますが！
こうゆう裏の仕組みをわかっていると楽しくなってくると思います！
最後に
この知識は今後自分でWebアプリケーションを作る際に役に立ちます！
特にCookieとセッションの周辺知識はログイン機能でセッションIDとUser_IDを必ず一致しているかと 紐づけることにより
current_user.idとして現在ログインしているかどうかを判断することができます。
これによってログインしていない人は見れないページとログインしている人は見れるページと区別することができます。
閲覧ありがとうございました！！！！！
何故エンジニアを目指しそうと思ったのか、プログラミングスクールを卒業しまたスクールのHappiness Chainさんに入会したのかをまとめて書いてみました。
自己紹介
初めまして！閲覧ありがとうございます。
2000文字近くありますが最後まで見てくださると幸いです。
工業高校卒業して社会人になってからの道のりを軽く紹介します。
3児の父で今年28歳になります。
色々とあり大学には行けずに18の頃から社会人になります。
お金の大切さは親から教えてくれたためコツコツと貯金をしてました。
真面目系バカです。
今はその貯金のおかげで仕事をやめ学習に集中できてます！
なぜエンジニアを目指そうと思ったのか
私は8年間、自動販売機の補充業務に従事していました。
今までは直接自販機まで行って通信していたものが技術の進化によって
オンライン通信でPCに売り上げが見れると言うWebアプリで
すごい技術が生まれ効率が向上し働き方が変わることを実感しました。
この経験から技術を活用して社会の便利さや効率を向上させる仕事に興味を持ち
『かっけえ！俺も挑戦してみたい！世の中を便利にして活躍したい！！』
と思いエンジニアを目指すことに決めました。
特にWebエンジニアに魅力を感じ自分でアプリケーション開発するぞと誓い
現在はその目標に向けて学習を継続し続けています。
私の今の現状
Webのことを右も左も分からない全くの未経験から
プログラミング学習を始めてもうすぐ６ヶ月目に突入します。
前にいたスクールを卒業したものの、タッチタイピングもできないWebの基礎も知らない
私が果たして実務に入って自社開発企業さんで戦力になるのか？
答えはNOです。面接受けた事ないのでわからないですが、
恐らく相手すらされないです。
今のポートフォリオと知識じゃ夢のまた夢です。
未経験者かつ学歴も資格も無い私が自社開発企業さんに就職するには、
ハイレベルなポートフォリオとアウトプットそれと技術ブログが必要です。
現時点の学習は1000時間突破してますが地頭が残念すぎるため
自分は他の人よりも一層努力して
学習しなければならないと確信しました。
もう＋1500時間ですかね！！
貯金はあるので焦らずに行きたいと思います。
自分は将来どんなエンジニアになりたいか
AIが凄すぎるため今後需要なエンジニアは
フルサイクルエンジニアだと私は思います
あと５年近く(長いかなあ)は掛かると思いますが、
自分の考えを具現化してサクサク作れるようなエンジニアを目指してます！
なぜHappiness Chainさんに入会したのか
自分が思うハイレベルのポートフォリオとは？から深掘りします
フロント(Next.js)とバック(RailsAPIモード)を分けて開発
インフラもコード化しDockerは必須
AWS ECSのFargateを使いデプロイ
GitHubActions使ってデプロイテスト自動化
↑JSからReactちょこっとかじって
これら２ヶ月間独学で学習しましたが、、、、
全く先に進んでるきがしませんでした。
とりあえず学びたい事だけをつまみ食い。
今思えば、基礎の基礎ができてないので当たり前ですよね。
PCでググってどうしたら身につくのか？どの教材書籍を買えばいいのかわからず
途方に暮れていたある日(202303/25頃)
日々Twitterで流れるHappiness Chainさん代表のゆうだいさんのつぶやきに
注目しまして、HP閲覧したら
『私が挑戦したい技術いっぱいあるじゃないですか笑！！』
鳥肌が立ちました。『この波に乗るしかねえ！』と思い
前のスクール卒業したら速攻で入ると誓い4/1に入会しました。
勿論、波に乗るだけではなく
1から提供してくれたロードマップ通りにもくもく学習していきます！！！！！！
入会してまだ9日目ですが、感想として一言
２ヶ月前に仕事を辞めてから
すぐ入会すればよかったと思うぐらい充実してるロードマップ
覚悟を決めました
つまみ食いはもうしません基礎から学びます。
長文失礼しました。
おわり
今後学習中の道のりや日常についてブログを書いていきます！
ここまで読んでくださった方ありがとうございました！
