20220312_アウトプット(ドメイン駆動設計)
ドメイン駆動設計の考え方、すごく面白い
- 最近ドメイン駆動設計(以下、DDD)を学びたくて色々読んでいる。
- 読み進めているもの
- ようやくの考え方が繋がり始めた気がする。
まず、DDDの単語の意味がわかった!
概念系
- ドメイン
- 領域という意味。システム化で解決したい要所はどの部分?
- ドメインモデル
- 解決したい要所の概念を抽象的に表現したもの
- なぜ?:プロダクトオーナー(ソフトウェアにしたい人)と開発者の共通認識・理解を深めるため
- 解決したい要所の概念を抽象的に表現したもの
- ドメインオブジェクト
- 解決したい要所の知識を具体的に表現したもの
- なぜ?:開発者が実際にコードに落とし込むため
- 解決したい要所の知識を具体的に表現したもの
- ユビキタス言語
- 境界づけられたコンテキスト
- モデルが適用される範囲を明示的に定義してそれぞれの中でモデル、言語の統一を目指すこと
- (例)”商品”という単語
- 販売者にとっての”商品”→商品名、価格、在庫数
- 配送者にとっての”商品”→商品名、配送先、配送状況
- (例)”商品”という単語
- モデルが適用される範囲を明示的に定義してそれぞれの中でモデル、言語の統一を目指すこと
感じたこと🌸
- 開発者は、プロダクトオーナーが普段どんな風に困っていてどんな部分を解決したいのかわからない。
- プロダクトオーナーは、普段行っている業務やサービスの中で、実は差別化につながっている知識(資産価値に繋がるもの)に気づかないことも多いだろう。
- だからこそ、開発者が対話を通じて引き出すの大事。「こういう意味ですか」って掘り下げるの大事。
- 具体化していくことで認識・方向性の改善が必要となり、徐々にドメインを育てていくため、テスト駆動開発やアジャイル開発と相性がいいのかと繋がった。
- 理想は1コンテキスト1アプリケーションなんだって(´-`).。oO(それ同士を同期or非同期で通信させる)確かにドメインぼやけるもんなあ。(理想と現実の最適解を探るの難しいけど面白そう)
DDDならではの単語系 〜値そのもの編〜
- 値オブジェクト
- システムに出てくる単位や値をオリジナルで定義すること
- ”不変”がポイントなので、交換はいいけれど、値そのものに代入して変更できないようにする
- (例)単価
- 0円以上1,000万以下の範囲に収まるシステムなので、その単価を設定する
- (例)単価
- エンティティ
- システムに出てくる値でもライフサイクルがあるもの(状態遷移)
- "可変"がポイントなので、振る舞いを通して、同一性を残したまま値を適切に変化させる
- (例)人
- 同じ「私」だけど、生まれた時からおばあちゃんになるまで変化がある
- (例)人
- ドメインサービス
- 値オブジェクトやエンティティに書いてしまうと不自然な操作だけを抜き取って定義すること
- (例)ユーザーの重複確認
- 値オブジェクト→自分自身に重複するユーザーがいないか聞く形となり不自然
- エンティティ→ユーザーを表すエンティティでありながらユーザーではなく不自然
- (例)ユーザーの重複確認
- 値オブジェクトやエンティティに書いてしまうと不自然な操作だけを抜き取って定義すること
- ファクトリ
感じたこと🌸
- ドメイン駆動設計の文脈で出てくる「エンティティ」は、永続化対象のデータをエンティティと呼ぶこととは別物とわかり超スッキリ。
- こうやって「同じ単語だけどドメイン駆動設計だと違う意味」が多いのでわかりづらいのかwww
- 「知らないところで値が変わることはない」「知らないところで状態が変わっていることはない」って保証するのって凄く大事だなと思った。なぜならば、それを前提で他を組み立てるため。
- 開発者同士がDDDを理解しドメイン知識はちゃんと大事にする!(値オブジェクトやエンティティは死守する!)という前提も大事だと感じた。
- ただのint型だと(最大値は2147483647、最小値は-2147483648)「そんなにいらんがな」ってなるところを、ちゃんとオリジナルの型で定義することで、不正な値を作らない”安全”にも繋がるし、コード自体に”100万以下なのね”と意味が生まれ可読性も上がるし、Goodだなあと思った。
DDDならではの単語系 〜値を成り立たせる編〜
- リポジトリ
- ユースケース/アプリケーション層
- 値オブジェクトやエンティティをまとめ上げて実際に機能として組み立てる層
- (例)ユーザー情報を登録する/変更する
- 値オブジェクトやエンティティをまとめ上げて実際に機能として組み立てる層
- 仕様
- あるオブジェクトが評価基準に達しているか判定するオブジェクトのこと
- 集約
- 必ず守りたい強い整合性を持ったオブジェクトのまとまりのこと(データの変更の単位)
- まとまりの中の親を「集約ルート」として、そこを起点にして集約同士でやり取りするようにする
- なぜ?:整合性を保つため
- まとまりの中の親を「集約ルート」として、そこを起点にして集約同士でやり取りするようにする
- 必ず守りたい強い整合性を持ったオブジェクトのまとまりのこと(データの変更の単位)
- 整合性(矛盾がない一貫性)を保つための方法(色々ある)
感じたこと🌸
- 「リポジトリ」何のためにあるんだろう??とずっと思っていたため”驚くほど柔軟性を与える”という言葉で「そういう役割だったのか!」と超スッキリ✨
- 整合性の部分は(実際の実装のところ)理解しきれない部分もあったので、その都度「絶対に必要なひとかたまりってどの範囲?」「実現するにはどの方法がベスト?」って調べようと思った。
(知らなかった)デメテルの法則
- オブジェクト操作において、メソッドを呼ぶオブジェクトは次の4つに限定されるよ
- (例)車を運転している時に、タイヤに直接命令しないのと同じように、それを保持するオブジェクトに対して命令を行うこと
(1)オブジェクト自身
(2)インスタンス変数
(3)引数として渡されたオブジェクト
(4)直接インスタンス化したオブジェクト
共通して大事なんだと感じたこと
DDDの意味がわかり始めてから「だから〇〇なのか!」と繋がったこと
- まず中心にドメインを作って(ドメイン層)、その周りにドメインを使った機能を作って(アプリケーション層/ユースケース層)、その周りに入出力・テスト・永続化の具体的方法・外部との連携(テスト/プレゼンテーション層/インフラ層)を作るオニオンアーキテクチャがGoodなのか!
- ドメイン知識となる部分=企業秘密になりうる部分なので、オープンソース上に少ないのか!
- 値単位で正確さを求めることから、静的型付言語との相性がいいのか!
- ドメインを表現するのが何よりの肝だから、ユビキタス言語などを通じてプロジェクトオーナーと開発者が対話するのが最重要なのか!
- DDDって「実はシンプルで当たり前のことを表現しているだけ」ってそういうことなのか
- 疎結合がもたらす恩恵ってそういうことなのか(例えばMySQLからPostgreSQLに変えるときインフラ層を直せば良いだけ)
- MVCとは全く別物なのか!(Railsのフレームワークを想像しながら読み進めると意味不明となる、全く別物、アーキテクチャの考えってそういうことなのか)
全体を通しての感想
- DDDを理解してからのオブジェクト指向の勉強がめちゃくちゃ面白い😭
- 今までは、クラスは〇〇、setterは〇〇など、単語の意味はわかるんだけど、それをどうやって活かしていくの?ってところが繋がっていなくて「こういうのどこまであるんだろう?覚えられないし辛い」って思ってた。
- でも「DDDの考え方ってこんなに面白いんだ!!」って思ってから、オブジェクト指向の単語を学び直したとき「DDDの中のここで使える引き出しが増えた」って感覚に変わって面白さを感じるようになった。
- 例えば、インターフェースってインターフェース自体はメソッド定義せず、
implement
したクラスが振る舞いを詳しく書くが、それをDDDで実現したい時に「リポジトリとインフラ層の実装をするときに活躍するのか!😍」って思えるようになった!(楽しいw)
- 例えば、インターフェースってインターフェース自体はメソッド定義せず、
- まだまだ途中なので読み進めていこう🔥
長くなりましたが読んでくれてありがとうございました!
20220305_プリンシプルオブプログラミング
読んだ本
www.amazon.co.jp/dp/4798046140
どういう本なのか?
- コードは一切ででこない。
- プリンシプルとは本質的な知識のこと。
- 「優れた方法」のエッセンスが凝縮された本だった☺️
元気をもらった言葉
まず抽象を学び、それから具体的なコードの技術を学んだ方が効率的に確かな技術が身につくのです。
- 半年前に比べると、抽象的な概念を知ることで、技術記事などを読むときに「設計思想で大事と言われている中のこの辺りの話かな」と最近、繋がることが増えてきた。
- ここから抽象を具体に繋げるための道具(PHP,Symfony等)を吸収していけばいいんだって前向きになれた。
なるほど!知識のアップデートに繋がったこと
単一責任の原則(=役割は1個にする原則)
- コードを修正する理由あるいはタイミングで分けるという意味でもある
🌷責任という言葉で悩んだ時は、修正時どうなるかという思考も一つの手なのかと思った。
信頼性(機能を維持する能力)には2つの側面がある
1. 正常な動作を保ち続ける:フォールトトレランス(fault障害 tolerance忍耐)
2. もともと頑丈か:(robustness堅牢性)ロバストネス
- 障害時にその部分だけ切り離す設計:フェールセーフ
- 例 石油ストーブ転倒したら勝手にストップ
- あらかじめユーザーが誤操作しない設計:フールプルーフ
- 例 座った時だけウォシュレット使用OK、電池+-逆だと入らない
🌷フェールほにゃららで混乱しがち😅維持するための機能と元々頑丈にしとこうとする2つの側面があるのね。
新しく知ったこと
- 再利用(全体あるいは一部を別のソフトウェアでも再利用できること)の「3の法則」
- 難易度3倍の法則
- 再利用可能なモジュールを作るには「一般化したらどうなるかな」と想像力&考慮が増えるため3倍難しいと言われている
- テスト3倍の法則
- 共有化する前に3つの異なるソフトウェアで使えるかテストする必要がある
- 難易度3倍の法則
🌷知らなかった。確かにピンポイントで解決しようとするよりも、一般化するの難しい。
7つの設計原理(コードレビューする時にこの観点持つといいよ)
- 単純原理‥シンプルで読みやすいか?
- 同型原理..同じものは同じに表現しているか?(単位、引数の数、使用順序等)
- 対称原理..対称性がとれているか?(beginがあったらendがある等)
- 階層原理..階層が整理整頓されているか?(抽象/具体、同じ処理は同じ層等)
- 線形原理..処理の流れは直線か?(反復・分岐を避け、上から下に向かった一筆書きGood)
- 明証原理..一見して明らかに正しいか?(不明瞭さを潰し、ロジックや変数名が直感的でわかりやすいとGood)
- 安全原理..ありえないという条件をあえて考慮しているか?(ある変数に対してNULLチェック、あるcase文に対してdefaoult句を考慮)
🌷レビューの業務も少しずつ増えてきたためナイスタイミング!と思った。
UNIX思想の一部「修復の原則」
- エラー検知は「けたたましく」w
- 修復が成功していないのに処理を継続してしまうと、どこで起きたのか失敗した影響範囲はどれくらいなのか特定しづらくなる
- ソフトウェアの使われ方にもよるが動作中に失敗したら、処理はストップし、エラーについてはできるだけ目立つ(早く気づいて判断できるように)するとGood
🌷さっきの信頼性の話あったものの(ソフトウェアの使われ方にもよるけど)おかしくなったら一旦ストップして、それにどれだけ早く多くの人が気づいて、復旧に取り組めるか大事だなって思った。
UNIX哲学の一部「即行プロトタイプ」
- まずは試作品を小さく早く作ろう、なぜならば下記の3を目指すため!
1. 性能こそ非常に高いが必要な機能が欠けている 2. 機能は多くなるが、性能が犠牲になっている 3. 両者の間に最適なバランスが模索され、本当に必要な機能だけ残して、適正なリソースで多くの事を達成できる
🌷試作品を作る目的が「3.」の部分であること知らなかった。たしかに「3.」に到達するには「1.2.」をどれだけスムーズに回せるかなのか。「なぜ」なのか知れたー💡
UNIX哲学の一部「フィルタ化」
- フィルタとは、入力ストリームをデータとして受け取り、何らかの加工を施し、加工したデータを出力ストリームに送り出すこと
- つまりソフトウェアは入出力のこと
🌷「ソフトウェア=目的のサービスを提供するもの」と思っていたけれど入力から出力までの一連の流れと捉える視点したことなかったので面白かった。また、その事を「フィルタ」っていうんだ。
UNIX小さな定理の一部
- 沈黙は金(極力表示出力を抑えるようにする)
- ファイルが見つからなかった時..何も表示しない
- 画面上意味のあるデータだけ表示して無意味な情報が並ばないようにする
🌷最初、黒画面うんともすんともいわず「?!」と思う事多かったけれど、こういう設計思想が元なのかーって納得。
この単語、自分理解してないなーと気づけたこと
- 非機能要件
- 「機能にしないことを決める」「機能じゃないけれどサービスとして提供する上で考慮する大事なこと」っていう認識であっているのかな🤔
- 機能ってどこまでなんだろう🤔(ロジックのことだけ?それともソフトウェアによる?) - いざ自分が機能要件と非機能要件を書こうとしたときに区分けできない(わかってない)ことに気づけた。
- 自己記述型
- 拡張性で「自己記述型」だと優れているっていう文脈で出てきた🤔
- 自己記述型???🤔(ぐぐっても)
- 言葉の通り「自分で完結して一個の部品として使いやすい」ってことなのか?
- プロトコルやファイル形式を設計するときに使うらしい。具体的に想像できなかったので、知識深めていこうと思った。
20210625_Symfonyのテンプレートとビューの基本について①
今日行ったこと
- Symfony入門のチャプター3(途中まで)
- ざっくりと章を読んだ後、始めから写経しつつ、どんな動きをするのか確認。
学んだこと
(1)Twigとはテンプレートエンジンの一つだった!
❓テンプレートエンジンって🤔
テンプレートを表示させるエンジンのこと。
❓テンプレートって🤔
今日の日付、ユーザー名など、表示の記述の中に様々な情報を組み込んだもの。
❓レンダリングって🤔
テンプレートによって読み込まれる際に、必要な値を必要な箇所に当てはめること。
❓なぜ、phpではなく、Twigを使うのか🤔
phpのHTMLへの埋込機能が長い間進化していないため。(Twigでは出来るテンプレートの継承が未対応だったりするとのこと・・😱)
(2)コントローラーと連携して表示する(render
)
❓どうやって連携させるのか🤔
render
メソッドを使い、コントローラーに「このテンプレートを読み込みます」と設定。具体的には、第1引数にはテンプレート名を、第2引数にはビューに渡したい値を配列(キーとバリュー)を使って記述する。表示させたい内容をビュー上に設定。具体的には
{{キー}}
と記述することで、バリュー(値)が表示される✨
(3)フォーム関係に便利なSynfony Formsがある!
- Railsのフォームヘルパーのようなものかなと思った。
- 使うには、オブジェクトの生成&そこにある3つのメソッドを呼び出して、必要なフォームを作成していく。
FormBuilder
を作成する。(コントローラーのcreateFormBuilder
メソッドを使い、オブジェクト生成する。)- フィールドを追加する。(フォームとしてどんな情報が必要か設定する。)
- Formを取得する。(
FormBuilder
のgetForm
メソッドを呼び出し、FormInterface
オブジェクトを取得することによって、入力された値をオブジェクトとして取得する。) - ビューの生成(
createView
メソッドを使い、FormInterface
オブジェクトを画面に表示するためのFomView
クラスのインスタンスを生成。それをテンプレートに渡して表示させる。)
👉つまり、フォームの内容をオブジェクトにすることによって、必要な範囲で、表示させたい分だけ表示させる仕組みなのかな?と思った。
感想
- オブジェクトのやりとりの部分が思ったよりもいくつもあった。まだまだ理解浅いけれど、このやりとりがいくつかあることによってその段階ごとの処理ができるのかなとも思った。
- フォームの部分って、セキュリティの面で狙われやすいと思うので、今はどんなふうに「データがやり取りされるのか」を見ていっているが「どうやったら安全に入力、保存、取り出し」できるのかなという視点も大事にしたい(その知識も深めたい)と感じた。知らないことだらけで面白い。
20210624_Symfonyのコントローラーとルーティングについて
今日行ったこと
- Symfony入門のチャプター2
学んだこと
(1)アノテーションという仕組みでルーティング設定出来るよ!
- Railsと同じように、コントローラーだけでなく、ルーティングの設定が必要である。
config
フォルダ内のroutes.yaml
にルーティングを設定する方法のほか、さらにシンプルな方法として「アノテーション」を使った設定方法がある。(アノテーション:英語で注釈という意味💡)- アノテーションとは、@で始まるコメント文のことである。クラスやメソッドの前に記述することによって、それらに何らかの情報を付け加える働きをする。
- ここで注意なのは、ルーティング=アノテーションという訳ではなく、「アノテーション」という仕組みを使えば、「コントローラー内にルーティングを設定できる!」という選択肢の一つであること!
🌟こんな感じ! 〜省略〜 use Symfony\Component\Routing\Annotation\Route; 〜省略〜 /** * @Route("/hello", name="hello") * / public function index() 〜省略〜
- アノテーションを使うときのポイントは3つある。
- 1つ目は、
use
を使って、必要な場所を読み込んでおく必要があること。 - 2つ目は、複数行のコメント形式で表示すること。つまり冒頭に
/**
を、末尾に*/
を用意する。(コメントアウトしているのに読み込まれるの不思議〜笑) - 3つ目は、アクションメソッドの前に設定すること。つまり、ここで言えば
function index
より前にアノテーションを用意する。
❓疑問❓ useってなに?
- useキーワードといって、「このファイル限定で、指定の名前空間を参照することを設定できる機能」のこと。
- バックスラッシュで示したそれまでの階層(今回でいえば
Symfony\Component\Routing\Annotation\
)の中の、最後のクラス名の部分(今回でいえばRoute
)を「読み込んでおくれ!」とphpエンジンに指示する。
(2)大体、AbstractControllerを継承してコントローラー作るよ!
AbstractController
とは、一言でいうと「便利な機能があらかじめ組み込まれているセット」である。(現時点では想像だが、Railsで7つのアクションを利用すると、必要なHTTPメソッドが使われるようなものなのかな?と思った。)Twig
と呼ばれるテンプレートエンジンも、AbstractController
を継承することで使えるようになる。
🌟こんな感じ! 〜省略〜 use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 〜省略〜 class HelloController extends AbstractController { 〜省略〜
(3)リクエストとレスポンスについて
ここは注意点なのかな?と思ったところだけ、ピックアップ。
- パラメータによる値の送信の時は、デフォルト値を設定しよう。なぜならば「必要な引数なしでアクセスした」と勘違いし、エラーが発生するため。
- JSON形式でレスポンスしたい時は、連想配列(キーとバリュー)としてデータを用意する。
- XMLデータの出力はちょっと面倒。なぜならば専用のResponseクラスがないので、配列をXMLデータに変換し、それをResponseでXMLとして送信するという一手間が発生するため。(そのために、コンポーネント(部品)である
Serializer
・XmlEncoder
・ObjectNormalizer
あたりを準備する。)
(4)ログ、どうやって出力するの?
- Synfonyにあらかじめ
LoggerInterface
があるので、引数で読み込み設定すればすぐ使えるよ。 - 具体的には、indexメソッドの時に使えるようにしたいのであれば、
public function index(Request $request, LoggerInterface $logger)
と宣言し、$logger->info(serialize($data));
と呼び出して、情報を書き出している。(info
は重要度の一つ。自分のみたい重要度に合わせて設定する。)
注:serializeとは、複数の要素を一列に並べる操作や処理のこと。
❓疑問❓ ->ってなに?
- アロー演算子といって、オブジェクト内のプロバティ(変数)とメソッド(関数)への道しるべ役をするもの。
- 具体的には
$logger
変数が保持するオブジェクトインスタンス内のinfo(serialize($data)
という意味になる。
感想
- 新しいこと勉強していて楽しかった。今日は集中できた。
- ついつい先延ばしにしたり、誘惑に負けそうになったりするけれど、自分にとって価値のあることに向き合えた時、終えた後に爽快感がある(笑)
- アノテーション=ルーティングだと思っていたが、アウトプットしたことによってそのインプットは間違えていると気づけた。
20210620_PHP
今日行ったこと
- PHP初級者試験勉強(第1・2章のおさらい)
学んだこと
- PHPの終了タグは
/
いらない。(<?php
で始まり、?>
で終わる) - 文字列における単一引用符(
''
)と二重引用符(""
)の違いは特殊文字が意味する値に置き換わるかどうか。(二重引用符(""
)の時に置き換わる) printf()
関数の浮動小数点において、指定された桁数以下が「5より大きい」と切り上げ・「5より小さい」と切り捨てを行う。(四捨五入じゃないよ!例えば指定された桁数いかが5.0111
だったら切り上げ、5
だったら指定桁数以下を切り捨てという形になるよ!)- 等価演算子
==
と、strcasecmp()関数
の違いは「大文字小文字」を区別するかどうか(=0=)💡
方法 | 大文字小文字を区別するか | trueの時 | falseの時 |
---|---|---|---|
等価演算子== |
区別する | 0を出力 | 何も出力しない |
strcasecmp()関数 |
区別しない | 1を出力 | 何も出力しない |
感想
- アウトプットのハードルを自分の中で上げてしまった。
- 「こんな小さなこと発信したら出来ない人って思われるかも」と怖くなってしまった。
- 自分の理解を深めるためなのに、人の目を気にしすぎていたのかも。ぼちぼち更新でも良いので、自分の中のハードルを小さくしようと思った。
- 最近は、ようやく引き継ぎ書の作成、後任者への引き継ぎ等がひと段落した。最後まで手を抜きたくなくて、そちらに専念していた。後悔なく過ごせたのでよかったかな。ここからは次のステップに向けて自分の知識のために時間を使おう。
20210515_アウトプット(TCP / IP)
今日行ったこと
- 1日で読めてわかるTCP /IPのエッセンス
学んだこと
TCP /IPって?
🤔私:「TCP / IP」と聞くけれど、これって何?
🥸先生:それぞれ最後の「P」は「プロトコル」を指しており、ネットワーク上においてデータ転送するにあたって必要なプロトコルの集合体という意味だよ。
🤔私:なぜプロトコル(規約)を作る必要があったの?
🥸先生:今では様々な機器が当たり前のように自由に通信することが出来るけれど、数十年前までは製造元が異なる機器、異なる製品のグループなどは簡単に接続できなかったんだ。プロトコルという形で共通の規約を決めて、様々な機器がその規約に対応することによって、機器の種類・製造元・ソフトウェア・製造時期に関わらず、様々な危機と通信できるんだよ。
😲私:「TCP / IP」のおかげで多数の組織のネットワークを相互に接続して、個々の機器の間で自由にデータ交換ができるんだね!
ここで注意点(TCP /IPには含まれていないもの・異なるもの)
- ネットワーク方式(有線のイーサネットや、無線LAN、モデムや専用線などのシリアル通信ごとの規格や規約)は含まれていないよ。(特定のネットワーク方式に依存せずネットワーク方式と連携するための仕組みは含まれている。)
- アプリケーションプロトコル(使用するアプリケーションの動作を定めるもの)とは異なるよ。
👉つまり、TCP /IPはネットワークシステムとアプリケーションの間に位置している💡
間を取り持つことによって、ネットワーク上でソフトウェアとハードウェアを繋ぎ、汎用的な通信サービスを提供できる。
TCP / IPを構成するプロトコル
中心となる、IP、UDP、TCP。他にもいくつかの関連したプロトコルが含まれている。
IPとは?「あなたのPCへデータを届けます!(機器まで)」👉機器間のデータ伝送。
- Internet Protocol
- 複雑に接続されたネットワーク上において、接続されている個々の機器が任意の相手にデータを送れるようにすること。
- 多数のネットワークに接続するには、ルーターと呼ばれる中継する機器を使って通信が必要。それをサポートするプロトコルが、IPである。
- IPにおいて重要や役割を果たすのが「IPアドレス」である。その機器が接続されているネットワークを識別する情報と、機器そのものを識別する情報が含まれており、それを使って特定の相手を指定できる。
- IPは、目的のプログラムを示すことはしない。エラー通知を送り返すが回復処理はしない。
ここでポイント!
UDPとは?「あなたのPCに(IPでデータを必要な機器に届けた後)目的のプログラムまで届けます!」👉プログラム間のデータ伝送。
- User Datagram Protocol
- IPで届けたデータに、ポート番号を付加して、プログラムに割り当てるプロトコル。
TCPとは?「エラーがあったときに対処します!」👉プログラム間のデータ伝送。
- Transmission Control Protocol
- 一方が送ったデータが、目的地へ全て届けられるのが任務だが、それがうまく行かなかった時に問題に対処するプロトコル。
- UDPと同じように、ポート番号を使って、データを相互にやりとりする通信路を提供。
- 明示的な接続関係であるコネクションをつくり、「どこまで送ったか」「どこまで受け取ったか」をチェック。
- 問題を発見したら、回復のために再送信を行う。(双方向のデータのやりとりを実現できることがポイント✨)
そのほかの関連プロトコル
プロトコル | 内容 | 補足 |
---|---|---|
ARP アドレス解決プロトコル | IPアドレスとMACアドレスの対応づけを行う。(Media Access Control) | TCP/ IPではIPアドレスを使うが、実際のネットワーク通信では個々の方式ごとに規定されているMACアドレスを使う。 |
ICMP インターネットコントロールメッセージプロトコル | TCP / IPを使ったエラーを通知したり、診断機能を提供したり、各種の制御を行ったりする管理プロトコル。(Internet Control Message Protocol) | |
ルーティングプロトコル | ネットワークを使ってルーター間でルーティング情報を交換する。 | 中継のための管理情報(ルーティング情報)が膨大な量になるため |
DHCP ダイナミックホストコンフィギュレーションプロトコル | IPの設定をサーバーで集中管理する。(Dynamic Host Configuration Protocol) | このサービスがあることによって、個々のパソコンで個別にIPアドレスの設定をする必要がなくなる。 |
SNMP シンプルネットワークマネージメントプロトコル | ネットワークを構成するスイッチやルーター、各種コンピュータなどのエラーや統計情報を収集し、動作を管理するためのプロトコル。(Simple Network Management Protocol) | ある程度規模以上の際、情報を自動的に収集/管理することでトラブル対応や運用の効率化が図れる。 |
DCS ドメインネームシステム | サーバーの指定やメールアドレスなどに使うドメイン名をIPアドレスに変換する。(Domain Name System) |
感想
- SymfonyのCLIの導入がうまく行かず、Kindleを検索していた時に、ふとTCP /IPってなんだっけ?と気になった題名の本を読み始めてしまった😂
- AWSで識別するためのIPアドレスを割り当てる作業をする時などにIPアドレスという単語に触れたが、識別するために「Elastic IPアドレスをアプリケーションと紐付ける」というざっくりとした理解だった。
- なので作ったアプリケーションの情報を送るにあたって階層に別れて必要なデータを送っていたり、アドレスの部分とそれを使えるホストの部分がIPアドレスの中に含まれていると知り、面白かった。
- Railsに比べてSymfonyの記事が全然見つからない😭見つけるのが下手なのかな。見つけてもバージョンが古かったりして「なんか違う気がする」と思うものが多かった💦チュートリアル全然進まなかった(;;)
- ここ一週間は気の向くままにプログラミングに関連する知りたいことを学べて幸せだった。知らないこと尽きなくて楽しい😍 でも、その分、読んだり見たりして、満足してしまい、アウトプットが疎かだった😅
20210501・2・3_アウトプット(オブジェクト指向・PHP)
行ったこと
5/1
- オブジェクト指向でなぜつくるのか(パッケージ・例外・ガベージコレクション・メモリの使われ方)
5/2
5/3
学んだこと
パッケージ・例外・ガベージコレクションについて
「オブジェクト指向」について、基本的なクラス・ポリモーフィズム・継承の他にオブジェクト指向型言語には便利な仕組みが3つある。
パッケージとは?
クラスをくくることができる仕組み。パソコンにある「フォルダ」のようなイメージ。「ただの入れ物」なので、パッケージに対してインスタンス変数やメソッドを作成することはできない。
パッケージのおかげで名前空間(同じクラス名であっても影響を与えない)ができるよ。
例外とは?
予期せぬ状況が起きたときに、「ここでエラーが出ているよ、助けて」と戻り値とは違う形式で返す仕組み。
A→B→Cという処理(サブルーチン)があった時に、今まではそれぞれにエラーが起きたときの処理を書いていて、重複していた。(冗長)また、そもそもの処理の書き間違えをすると、エラーを吐き出すことができない恐れもあった。
その問題を解決するために、上記の例で言うと、Cでエラーが起きたら、Bは「Cで起きているよ(詳しくはCを見て)」と宣言するだけにしたり、例外を宣言しているメソッド側において、例外を処理するロジックを書かないと(エラーを発生させる側・エラーを受け取る側が噛み合っていないと)プログラムをエラーにさせるようになった。
ガベージコレクションとは?
インスタンスのゴミを自動で集めて削除する仕組み。今までは、プログラムを作成するときに、どのようにメモリを解放するか・解放の処理も手作業で行っていた。それらを、プログラム言語側の処理として行ってくれる機能。
メモリの使われ方
一時的にメモリを保存しておくところとして「静的領域」「スタック領域」「ヒープ領域」の大きく3つある。
領域 | 内容 |
---|---|
静的領域 | アプリの開始〜終了まで変わらないメモリ領域。グローバル変数やクラス情報など。(プログラムの実行時に変化しないから「静的」だよ!) |
スタック領域 | スレッドごと(プロセスよりも小さな単位)に作られるメモリ領域。ローカル変数・関数の引数・戻り値など。効率よくするために、「後入れ先だし」なことがポイント。 |
ヒープ領域 | 動的なもののために作られるメモリ領域。インスタンスが作られるたびにここが使われるよ!(OSや仮想マシンが割り当て・解放処理を管理してくれるよ) |
ポイントとしては、
- 前述したガベージコレクションは、「静的領域」と「スタック領域」と手を繋いでいないメモリを「ゴミくず」と判断して、削除していること。(つまり、その2領域から無駄に参照されていると残り続けてしまう)
- クラス情報は、インスタンス変数を生成する前に、一度読み込まれる(全てのクラス情報を一気に読み込むか、必要な時に逐次読み込むかは言語仕様によるが、JavaやPHPは後者)
- インスタンス変数は、
new
をした時にインスタンス自体は「ヒープ領域」を使用するが、参照元などの「インスタンス変数」自体は、ポインタ(住所)のみ対象エリアに格納される。(インスタンス変数の中身によって「静的領域」あるいは「スタック領域」へ。) - ポインタで格納するメリットは、内容の大きさに関わらず常に同じ形式でインスタンスを管理することができるため。(例えば、北海道に住んでいても東京に住んでいても(実際に住んでいる土地の大きさは違うけれど)「住所」で表現した時には葉書一枚に収まるという意味)
- 上記らのことを踏まえてインスタンスのメモリが使われる時の注意点としては、メモリの一時保存先が異なることから、作ったインスタンスの数と、それに納める内容の数が一致していないと、納め先がなくなり、意図しない代入(入れるところないから上書きしよう)とわかりづらいバグを起こすことがあるよ!
PHPの配列・関数について
配列について
- Rubyで言うと「ハッシュ」のことを「連想配列」と言う。
- Rubyで言うと「配列」のことを「数値配列」と言う。
- 配列を
[ 配列内容];
で表現できるようになったのはPHP5.4からなんだって!(それまではarray(内容);
で表現) foreach
について、要素の中身を変更するには、$key変数を配列のインデックスとして使い、要素の中身を変更した後、その内容を表示するにはもう一度foreach
をする。(「$key変数を配列のインデックスとして使う」というのは、例として、foreach($meals) as $dish => $price { 内容〜
でキーを$dishとして設定した後、$meals[$dish] = $meals[$dish] * 2;
のようにキーに対して2倍の処理と代入すると、値を変更できるという意味)
覚えた単語 | 意味 |
---|---|
in_array | 要素から値を探してtrueかfalseで返す |
array_key_exists | 要素からキーを探してtrueかfalseで返す |
array_serach | 要素から値を探してキーを返す(ホテルの受付のイメージで覚えた!「この部屋を予約しているんですが」「はい、鍵です」のイメージ) |
unset | (キーと値を指定して)対象の要素を消す |
array_reverse | 配列の中身を逆順にする |
array_splice | 対象の値を削除して置き換える |
explode | 文字列を配列にする |
implode | 配列を文字列にする |
sort | 並び替え(数値配列で使う) |
asort | 値で並び替え |
ksort | キーで並べ替え |
関数について(ユーザー定義関数のところまで)
function 関数名(引数) { 内容 }
で定義して、関数名(引数);
で呼び出す。- 引数の数が合わないとエラーが出ることはRubyと同じ。
- Rubyと同じようにデフォルト値を設定することができる。デフォルト値に設定できるのはリテラル(数値や文字列を直接書いたもの)のみ。(変数に変数を定義はできない❌)設定する際は、引数として必須のものを引数内の前半に書き、デフォルト値を設定するような任意のものは後半に書く。
感想
- オブジェクト指向の本のおかげで、背景知識が深まり、配列や関数を学んでいるときにちょっとしたこと(例えば本の中で「引数の名前が関数外の変数を同じ名前の場合に引数を変更しても関数外でも変数に影響を与えない」と言う文章が出てきたときに「ああ、この背景としてメモリの使われ方が違うからだ」と感じるようになったこと)が嬉しかった。
- 実際にコードを書いているとついセミコロンを忘れる😅
- つい、理解が遅いのでは?と焦ってしまう自分がいるが、着実に理解はしていると励まして進めようと思う。