4月10日、金曜日。

ひきつづき株プログラムの開発。ブログにまとめるにはちょっと時間が足りないぐらい集中したし、今日で学んだことは多い。詳細は明日書けたらいいなと期待しつつ、とりあえず簡略にまとめておこう。

• 昨日、プログラムのパッケージ化ができた。このときはまだ __main__.py が動く段階* パッケージをコマンドとして利用できるように setup.py などを準備できた。ローカルでは duedeli コマンドで任意の日付の有価証券報告書を閲覧できるようになった。

• find_packages() で見つけてもらうには __init__.py が必要なことを理解した* パッケージをPyPi(Python Package Index)に登録できた。

• https://qiita.com/kinpira/items/0a4e7c78fc5dd28bd695#setuppy%E3%81%AE%E4%BD%9C%E6%88%90 * https://blog.amedama.jp/entry/2017/12/31/175036 * パッケージをコマンドライン、ライブラリとして利用しやすいように改修した* データベースの利用を外した* コマンドラインとライブラリとで標準出力やログの扱いを切り替えられるようにした* 開発者モードを追加した最後に記載した改修を進めるなかで、依存関係を整理したメリットが多くでてきた。「有価証券報告書の解析」が「プログラム処理進捗の出力」に依存してしまっていると非常にややこしくなってしまうところだったが、出力を解析に逆転させることでプログラム改修が容易になったことを感じた。

とくに重要なのは、必要になったタイミングで好きに逆転をさせられるところ。『Clean Architecture』で語られていたように、必要になるまで「保留」させる余裕や技術も持てたように思う。いわゆる「完全にわかった」状態だ。

上記に集中しながらではあるが、『脱力タイムズ』は欠かさずに視聴。どうかコロナウイルスを真正面から笑い飛ばしてほしい、と切に願う。「リモート出演」だって「キャスタ−の距離を2m空ける」だって「透明なパーテーションで区切る」だって、何でも料理できるのがこの「ニュース番組」の強さのはずだから。ただ『ヒルナンデス』は強敵だぞ〜。

2020年4月9日、木曜日。

夕飯にホットクックでぶり大根をつくった。砂糖を大さじ4杯も入れるように書いてあったけど小さじ４杯の誤植だろう、と思ってかなり減らしたけれどそれでも甘かった。みりんだけで作ればよかったかな。

ひきつづき『clean architecture 達人に学ぶソフトウェアの構造と設計』を読む。第Ⅲ部の途中から。

• 第9章: LSP:リスコフの置換原則
  • （『アジャイルソフトウェア開発の奥義』からの引用で）S型のオブジェクトo1の各々に、対応するT型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型であると言える* インターフェイスだけでなく、アーキテクチャのレベルでも置換可能性を適用すべきである
  • （感想）次のnoteがわかりやすかった。 https://note.com/erukiti/n/n88b8ed99f1e1
  • （感想）「引数、返却値の型を合わせる」みたいなシンプルな理解だと誤る。RectangleとSquareの例を思い出し、「呼び出す側が想定している動作をするか」みたいな観点で考えるべき。
• 第10章 ISP:インターフェイス分離の原則
  • 必要としないモジュールに依存しないようにする
  • モジュールだけでなく、アーキテクチャレベルでも意識する必要がある
  • システムがフレームワーク、フレームワークがデータベースにそれぞれ依存すると、データベースの変更がフレームワークにもシステムにも影響する
• 第11章: DIP:依存関係逆転の法則
  • インターフェースは実装よりも変化する頻度が少ない
  • システム内の「変化しやすい」要素に依存しないようにしたい
  • そのため変化しやすい具象クラスを参照・継承しない
  • オブジェクト指向においてはAbstract Factoryパターンの利用があてはまる
  • DIPはアーキテクチャにおいても重要で、「依存性のルール」として現れる会社においても「依存関係逆転」は使えるかも。上司と部下のどちらが「変化しやすい」のかを見極めないといけないが（むしろ変化してほしい上司／部下がいたりして）。

株のプログラムの依存整理も完了。有価証券報告書の解析を関心事の中心として、これに依存させるように各モジュールを整理していった。上手くはいったけれど、まだメリットを実感するような設計にはなっていないような気がした。

またいろいろと学習を進める中で、 __main__.pyをプログラムのソースディレクトリ直下に置くことで単独のアプリケーションとして動かすことができることも理解できた。ゼロから学ぶPythonに大変助けられた。 pytestもやっと開始。 setup.py の作成がちょっと怖かったけれど、なんとか上手くいってよかった。

pip install -e .の意味はサッパリ理解していない。xbrlファイルの解析に失敗している企業が多くあったので、pytestを使いながら少し修正。いい感じに成長できていて晩酌がはずんだ。

2020年4月8日、水曜日。

以前買ったバターケースを使ってないことを思い出してさっそく使う。バターをケースに入れる前に10gずつに等分したのだけれど、これをケースにしまうのが大変だった。外にいようが家にいようが、日常ってのは面白いものだ。

ひきつづき『clean architecture 達人に学ぶソフトウェアの構造と設計』を読む。第Ⅲ部の途中まで。

• 第7章: SRP:単一責任の原則* モジュール（ソース、関数、データをまとめた凝集性のあるもの）はたったひとつのアクターに対して責任を追うべきである* アクターの異なるコードは分割するべきである* 解決策のひとつとして「データを関数から切り離す」戦術がある* 同じクラスを利用せず、アクター別のクラスを用意する* 異なるクラスが増えすぎて収拾がつかない場合にはFacadeパターンを利用する* 切り離す前のクラスに重要な（共通的な）メソッドとFacadeパターンを載せる戦術もある* 単一責任の原則は、関数レベルの原則であり、コンポーネント・アーキテクチャレベルでも単一責任の原則はある（名前は異なる）

• 第8章: OCP:オープン・クローズドの原則* ソフトウェアの振る舞いは、既存の成果物を変更せずに拡張できるようにすべきである* この原則はクラスの設計指針というより、むしろコンポーネントのレベルを考慮したときに重要なものとなる* コンポーネントからコンポーネントへの線（依存）は、すべて一方通行にする* コンポーネントは、「自分自身を変更したときに影響を及ぼしたくないコンポーネント」に対して依存させる* 感想: ここでいう「影響」は実際の処理だけではなく、前述されているデプロイなども含まれているだろう* アプリケーションの中心となる関心事を処理するビジネスルールをふくむコンポーネントは特権的な位置づけを得るべきである* 特権的なコンポーネントは、他のすべてのコンポーネントの変更による変更の必要をなくすようにする

Pythonのパッケージ、モジュールのimportについて。やっとひとつ理解できた。まだ言語化できていないのだけれど、揮発しないうちに頑張って実践してみる…ということでかれこれ4,5時間熱中して株プログラムの依存関係を整理してみた。IDEでもうすこし楽にできればいいのだけれど、とりあえずは全部タイピングして血肉にできた。

このあたりの実装ができるようになると、あらためて設計の難しさに立ち戻ってくる。もう何度か忘れてしまったけれど、もう一度DDDをやりなおそうか。

2020年4月7日、火曜日。

午前中に配偶者がグズったのを鎮めたあと、そのまま起きっぱなし。家電量販店のスタッフが家に来てくれて、食洗機の導入について見積もりをしてもらった。恐縮してばっかり。

昼はマクドナルドでテイクアウトをした。ちょっと買っただけなのに1000円もしたので驚き。まだハンバーガーが70円ぐらいだった時代に生きていたが、今日をもって更新することにしよう。こうして大人になる。

MacbookProのデータがちょっと溜まってきたので再インストールを実施。2ヶ月半ぶり2度目。

前回やったことをリスト化したり、インストールするアプリケーションは brew cask installでまとめたり、それらをシェルスクリプトにしたりと、かなり工夫をしたので一瞬で終わる予定だった。しかし始めてみるとCatalinaになった影響で、シェルがbashからzshに変わったことが大きく影響し、かなり時間をくってしまった。

とくに .bash_profile などを .zshrcなどに載せ替えるのが大変だった。プロンプトの書き方も変わっていたようで、見様見真似ですこしずつ改修をしていった。というかまだzshの使い方がわからない。

そんな感じで最初につくった「再インストールバッチ」の大部分を編集しながら再インストールをしたので、完了直後に思い切って再度インストールを実施してみた。今度は思い通りに1時間程度で終わり、実際の作業は数分で環境構築ができるようになった。このブログも昨日と同じ感覚でかけるし、Pythonもnodeも好きなバージョンを選べる。非常に大きな一歩だと思う。

配偶者が『テラスハウス』を見ていたのが視界に入ったので、なんとなく一緒に見た。

「テラハ」は正直に言ってもう役目を終えたと思う。なんて書くと「バチェラーに負けたのか」と受け取られるかもしれないので説明するが、ジョブ理論に照らし合わせれば間違いなくインスタやYoutubeの「モーニングルーティン」に負けたのである。

テラハもそれを薄々感じているのか、「男女のオシャレでヘルシーな共同生活」を押し出すのではなく、むしろ「生活感」を出すようにシフトした。すごい雑に言えば 「シェアハウスあるある」へシフトしている のだと思う。

なんでそんなことになったのか。端的にテラスハウスに「憧れ」を投影する人が減ったからだろう。憧れの人生、恋愛、暮らしはインスタに取って代わった。たとえばさ、あそこに出てる男女に「テラスハウス出演権」と「インスタのフォロワー○万人増加」のどちらを選ぶか聴いてみたらいい。

ちなみにバラエティ的な面白さはバチェラーと「オオカミ君」にとられたことも書いておこう（名前うろおぼえ。調べたら『オオカミちゃんには騙されない』でした）。そんなわけで、テラスハウスは僕にとっては南キャン山里のワードセンスを楽しむ番組になっていた（それで面白いんだからビックリする）。

そしてそんな中でひとり奮闘している 木村花選手に強いエールを。どんな相手でもロックアップから始める姿勢、攻めも受けもきっちりやりきる覚悟。それらは私が今日唯一学んだことだ。

2020年4月6日、月曜日。 珍しく午前中に起床。サボり気味だった掃除洗濯を早めに済ます。早めに買いものを終えて、ホットクックでいくつか常備菜を準備。

午後は『[Clean Architecture](/tags/Clean Architecture) 達人に学ぶソフトウェアの構造と設計』を読みなおすことにした。とりあえず第Ⅰ部。

• 第1章: 設計とアーキテクチャ* ソフトウェアの設計＝アーキテクチャは、システム構築・保守にかかるリソースを最小限に抑えることを目的とする* 「動くものを作る」姿勢だと、時間経過に応じてチーム・プロダクトの生産性は落ちていく* そのようにして生産性が落ちたプロダクトは、スクラッチから再設計されても同じように崩壊するだろう* 第2章: 2つの価値のお話* ソフトウェアは、「振る舞い（仕様）」と「アーキテクチャ」の2つの価値を持つ* 現場では「振る舞い」が優先されるが、 「アーキテクチャ」を優先させなければならない* 「完璧に動作するが変更できないプログラム」と「動作しないが変更の用意がプログラム」のどちらがよいか？

• 「アーキテクチャ」は第Ⅱ領域、「振る舞い」は第Ⅲ領域* 開発者はステークホルダーとしてビジネスマネージャー（最近なら「プロダクトオーナー」だろうか）と闘争し、アーキテクチャの重要性を伝える責務があるそして第Ⅱ部。

• 第3章: パラダイムの概要* 3つのプログラミングパラダイムは、「何をすべきでないか」という枠組みを提供した* 「構造化プログラミング」は、直接的な制御の移行に規律を課す* 「オブジェクト指向プログラミング」は、間接的な制御の移行に規律を課す* 「関数型プログラミング」は、代入に規律を課す* 3つのパラダイムは、アーキテクチャの重要な関心事とそれぞれ対応する* 構造化: 機能（の分割）

• オブジェクト指向: コンポーネントの分離* 関数型: データ管理* 第4章: 構造化プログラミング* 構造化プログラミング以前、goto文の時代は、プログラムの処理はあちこちへ飛んでいた。そのためモジュールの分割、それぞれのモジュールの証明（テスト）ができなかった* 構造化プログラミングは、goto文を「順次」、「選択(if/then/else)」、「反復(do/while)」で置き換える発想である* 構造化によりプログラムは大きな機能を小さな機能に無限に分割することができた。今日のプログラミングはこれが基本* モジュールを分割することで、分割された機能は「反証可能」なものになった* 科学が「真であること」を証明できないように、テストも「正しく動作すること」を証明できない。可能なのは「誤った動作をすること」を証明することである（感想: だからTDDはfailから書き始める）

• 第5章: オブジェクト指向プログラミング* 優れたアーキテクチャの基本は、オブジェクト指向設計の原則と似ている* オブジェクト指向の重要な点は、 ポリモーフィズム を安全に提供することにある* ポリモーフィズムによって、上位モジュールが下位モジュールに依存していた関係性を逆転することができる（依存関係逆転）

• プラグイン・アーキテクチャ（OSは個別のIOデバイスに依存しないようにする）を元にした発想* ポリモーフィズムを利用することで開発者は、依存関係を制御の流れと関係なく好きなように制御できる* 依存関係を逆転・制御することで、一緒くたになっていたコンポーネントを独立してデプロイ・開発することができるようになった* 第6章: 関数型プログラミング* 関数型プログラミングの特徴は、可変変数を持たないことだ* 可変変数を持たないことで、競合・デッドロック・並行更新のトラブルを排除することができる* この「不変性」を実際に使うためには、サービスを「可変コンポーネント」と「不変コンポーネント」に分離させることが重要* （第3章からのまとめでを含めて）ソフトウェアは、「順次」「選択」「反復」と「間接参照」で構成されている。

とくにポリモーフィズムが大事だということがハッキリと伝わってくる。アナロジーを思いついたのでnoteポリモーフィズムと野菜炒め〜『クリーン・アーキテクチャ』を理解するためにを寄稿してみた。

---それでPythonで依存関係の制御を行おうと、実際のコーディングを勉強。Inject と Injectorの2つのライブラリがよく使われているみたいで、とりあえず Inject から使ってみようか。次の2つのQiitaをもとに勉強する。

• [Python で DDD するなら Inject がオススメ](https://qiita.com/ledmonster/items/3b108be6f0967bfe1093)

• PythonでDI(Dependency Injection)

2020年4月5日、日曜日。 コンビニでコピーをとる以外には家にいた日。外出自粛というより日常を送っていたらそうなった、ってだけ。 SlackApp用のLambdaプロジェクトはいったん完成。App（ボット？）に対してメンションを送れば、その内容をもとにコマンド（呼び出すAPI）を使い分けるようになった。以前にGolangでも作ったのだけれど運用面を考えればPythonのほうがよかった。

とりあえず「モノがつくれる」レベルにはなったので、そろそろPythonのプログラミング技術をちゃんと勉強しようと思う。個人的にはコーディングよりもモジュール・パッケージ構成のベストプラクティスを知りたい。とくにクリーン・アーキテクチャをどうやって実現しているのか。書籍はあまり見つからなかった。

ちなみにできるかぎり端末を汚さないようにしていたが、やはりnpmは必要そうなのでちゃんとnodebrewを学んだ。 export PATH=$HOME/.nodebrew/current/bin:$PATH でパスを通しておけば nodebrew useで指定したバージョンをcurrentに配置して使える、ということを理解して「なるほどな〜」って感じ。こういう少しの成長が大切。

EDINETのxbrlファイル解析は、デモ製品が完成した。自分の作ったプログラムでは、良品計画、河西工業、ムゲンエステートあたりが「超割安」と判断されている。とくに良品計画は「10倍でも不思議じゃない」ぐらいの値になった。明日実際に有価証券報告書を見たりしてみよう。