【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅲ部 第9章

はじめに

前回の続き

huji-mori.hatenablog.com

第Ⅲ部

第9章 LSP:リスコフの置き換え原則(LSP:Liskov Substitution Principle)

リスコフの置き換え原則 →交換可能なパーツを使ってソフトウェアシステムを構築するなら、個々のパーツが交換可能となるよう契約に従わなければいけない →これを破ると呼び出し側でオブジェクトの型を意識するようなコードを書かなければならない、という雑な理解でいいのかな・・・? →この章の説明だけだと分かったようで分からない感ある

以上。

【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅲ部 第8章

はじめに

前回の続き

huji-mori.hatenablog.com

第Ⅲ部

第8章 OCP:オープン・クローズドの原則(OCP:Open-Closed Principle)

オープン・クローズドの原則 →ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべき →アクターの異なるコードは分割するべき →ここで言う「アクター」はそのモジュールを利用するステークホルダーを指す

推移的な依存関係 →ソフトウェアのエンティティが自分が直接つかっていないもに依存すべきではない →以下のようにCに対して依存しているBという機能があり、Aという別の機能がBに依存していた場合、Aは推移的にCに対して依存している。という解釈で良いのかな? A→B→C

以上。

【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅲ部 第7章

はじめに

前回の続き

huji-mori.hatenablog.com

第Ⅲ部

第7章 SRP:単一責任の原則(SRP:Single Responsibility Principle)

単一責任の原則 →モジュールを変更する理由はたったひとつであるべき →アクターの異なるコードは分割するべき →ここで言う「アクター」はそのモジュールを利用するステークホルダーを指す

以上。

【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅱ部 第6章

はじめに

前回の続き

huji-mori.hatenablog.com

第Ⅱ部

第6章 関数型プログラミング

アーキテクチャと可変変数

アーキテクチャが可変変数に配慮すべき理由は下記の原因が可変変数によるものだから。

  • 競合状態

→簡単に言うとプロセスやスレッドが同じ変数、ファイルなどのリソースを同時に参照しようとすること。

→プロセスやスレッドがリソースを参照した時に競合し、永遠に処理が終わらない状態になってしまうこと。

  • 並行更新

→プロセスやスレッドが同じ変数、ファイルなどのリソースを同時に更新しようとすること。

3つのパラダイム

  • 構造化プログラミング

→直接的な制御の移行に規律を課す

→「直接的な制御の移行」ってどういことだっけ・・・?後で調べる

→ 間接的な制御の移行に規律を課す

→「間接な制御の移行」ってどういことだっけ・・・?後で調べる

→ 代入に規律を課す

眠いので今日はここまで。

以上。

【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅱ部 第5章

はじめに

前回の続き

huji-mori.hatenablog.com

第Ⅱ部

第5章 オブジェクト指向プログラミング

依存関係逆転

「依存関係逆転」という言い回しが以前から腑に落ちていなかったが、下記の記事の説明で納得。

zenn.dev

オブジェクト指向(OO:Object Oriented)とは

以下、書籍から引用。

OOとは「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」である。

注意点としては

ポリモーフィズムが実現できる = オブジェクト指向 ではない。

今日はここまで。 以上。

【メモ】【WSL2】【Ubuntu】【yarn】yarn serve を実行して「00h00m00s 0/0: : ERROR: [Errno 2] No such file or directory: 'serve'」となった時の解決方法

前提

$ uname -a
Linux DESKTOP-CDBO27E 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

何が起きた?

  1. yarn serve 実行したい
  2. cmdtest を apt install でインストールする
  3. yarn serve 実行
  4. 「00h00m00s 0/0: : ERROR: [Errno 2] No such file or directory: 'serve'」が表示される
$ yarn

Command 'yarn' not found, but can be installed with:

sudo apt install cmdtest

$ sudo apt install cmdtest
...

$ yarn serve
00h00m00s 0/0: : ERROR: [Errno 2] No such file or directory: 'serve'

Why ?

調べていくと stackOverflowの以下の回答に行き着いた。

ja.stackoverflow.com

以下原文の日本語訳を引用。

ディストリビューションなどが明記されていないのであれなのですが,ざっくりといえば多くのディストリビューションにおいてはディストリビューションが提供しているパッケージはyarnpkg,yarnが独自のdebrpmリポジトリで配布してるのがyarnになっていることが多いようです.また,ディストリビューションの配布しているパッケージではyarnコマンドではなくyarnpkgコマンドに置き換えられていることがあります.(DebianUbuntuなどでディストリビューションの配布しているyarnpkgパッケージには/usr/bin/yarnは含まれていません.)

しかし,これは理由というよりは結果です.なぜディストリはyarnではなくyarnpkgでこのパッケージを提供しているのでしょうか.それはyarnpkgとは全く関係のないpythonのパッケージであるcmdtest(Ubuntuのバージョンによってはデフォルトでインストールされていることがあるようですが)が/usr/bin/yarnをリザーブしており,yarnはcmdtestのエイリアスになっていることがあるようです.

曰く、DebianUbuntu などのディストリビューションの yarn は Python の cmdtest というパッケージに対するエイリアスになっているらしい。

言われてみると apt installを実行した際にPython のパッケージがインストールされていて「何故?」と疑問に思ったが、こういうことだったのか。

Reading state information... Done
The following additional packages will be installed:
  python3-cliapp python3-markdown python3-packaging python3-pygments python3-pyparsing python3-ttystatus
Suggested packages:
  python3-xdg python-markdown-doc python-pygments-doc ttf-bitstream-vera python-pyparsing-doc
The following NEW packages will be installed:
  cmdtest python3-cliapp python3-markdown python3-packaging python3-pygments python3-pyparsing python3-ttystatus
0 upgraded, 7 newly installed, 0 to remove and 195 not upgraded.
Need to get 808 kB of archives.
After this operation, 4394 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu focal/universe amd64 python3-cliapp all 1.20180812.1-3build1 [44.5 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal/main amd64 python3-pyparsing all 2.4.6-1 [61.3 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal/main amd64 python3-packaging all 20.3-1 [26.8 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal/main amd64 python3-markdown all 3.1.1-3 [59.3 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal/universe amd64 python3-ttystatus all 0.38-4 [14.7 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal/universe amd64 cmdtest all 0.32.14.gcdfe14e-1 [21.8 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 python3-pygments all 2.3.1+dfsg-1ubuntu2.2 [579 kB]
Fetched 808 kB in 2s (426 kB/s)
Selecting previously unselected package python3-cliapp.

解決方法

解決方法は以下のリンク先に記載の通りになる。

https://stackoverflow.com/questions/46013544/yarn-install-command-error-no-such-file-or-directory-install

下記コマンドを順に実行すればOK。

$ sudo apt remove cmdtest
$ sudo apt remove yarn
$ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
$ echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
$ sudo apt-get update
$ sudo apt-get install yarn -y
$ yarn v
yarn run v1.22.19

yarn のインストールが終わった後、yarn serve が実行できることを確認👍。

❯ yarn serve
yarn run v1.22.19
$ serve
UPDATE AVAILABLE The latest version of `serve` is 14.1.2

   ┌──────────────────────────────────────────────────┐
   │                                                  │
   │   Serving!                                       │
   │                                                  │
   │   - Local:            http://localhost:3000      │
   │   - On Your Network:  http://172.24.35.23:3000   │
   │                                                  │
   │   Copied local address to clipboard!             │
   │                                                  │
   └──────────────────────────────────────────────────┘

以上。

【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅱ部 第3~4章

はじめに

前回の続き [https://huji-mori.hatenablog.com/:embed:cite]

第Ⅱ部

第3章 パラダイムの概要

プログラムのパラダイムの変遷

プログラムのパラダイムは「構造化プログラミング」→「オブジェクト指向プログラミング」→「関数型プログラミング」と変遷していった。 3 つのパラダイムでは以下の事を「すべきではない」ものとしてしている。 - goto 文 - 関数ポインタ - 代入

第4章 構造化プログラミング

構造化プログラミングのプロセス

構造化プログラミングはモジュールを小さな機能に分割して、分割されたそれらが正しいことを証明するプロセスでした。 しかし、機能の「正しさ」を証明することに対してプログラマー達は興味を示しませんでした。結果、このプロセスは陰をひそめていくことに。

このプロセスの次に出てきたものが「機能が正しくないことを証明できないことによって、その機能の正しさを明らかにする」というものでした。 →この考え方が後のプログラムのテスト手法に活きていくのですかね?

今日はここまで。 以上。