2020年4月13日、月曜日。

昨日につづいて雨が降っていて、かつ寒くなってきた。毎年会う人に伝えているけれど、「４月は寒い」ってことをみんな毎年忘れている。私も今日は忘れていた。

株のプログラムを書いたりしている間、投資に関するYoutubeを見ることが多かったせいで、Youtubeのレコメンドがとうとうお笑いの動画から投資、自己啓発へ移ってしまった。「あれを買え」、「これを捨てろ」みたいな動画ばかりで、なかなか面白い。自宅待機でヒマなのでモノマネの練習に励んだ。

「楽天経済圏」という用語もはじめて知った。そのうち楽天が紙幣刷ったりするのか？

ここ2週間ぐらいで得た知識を、「あとで後悔しないPythonのディレクトリ構成をつくってみる」(https://qiita.com/kobori_akira/items/aa42790354654debb655)として[Qiita](/tags/Qiita)にまとめた。とても小さな記事だが、分量はそれなりにある。この記事を書くことで自分のナレッジも定着した感じがする。

余った時間で、食洗機を設置できるように台所回りの片付けと掃除。久々にメラミンスポンジを使って本格的に掃除したかも。

2020年4月12日、日曜日。

去年の夏に引っ越しをしたのだけれど、その決断がいい方向に転んだことを実感している。以前はほぼワンルームのマンションに配偶者と住んでいたけれど、この状態のまま外出自粛になっていたら辛かったかもしれない。それまでパーソナルスペースを外部に頼っていたから。

新しく借りた家にはロフトがついていて、こういった季節であれば苦なく過ごせることができる。ラップトップとKindleを持ち込めば、好きなだけ集中できる環境が手に入る。

ということで集中した結果、株プログラムがいよいよ完成。スクレイピングをする前提のため大々的に公開することはできないが、個人で使うぶんには十分なプロダクトになったと思う。

さっそくこれで「かなり割安で、自己資本比率も高く、少額で買える株」をあらためて分析してみた。結果としては次の企業がピックアップされた。（※６月提出分の解析はエラーになってしまった。不具合修正中）

• 高橋カーテンウォール工業株式会社* Ｊトラスト株式会社* 日本乾溜工業株式会社* 株式会社グリーンズ* 株式会社エヌリンクス分析の弱点は「直近２年の営業利益しか見ていない」ということだけれど、それは今後調整していけばいい。このドメインモデルをアプリケーションの中心として設計できたことが非常に大きいと感じている。上記の企業を買うかはともかく（軍資金は納豆に投資するかもしれないし）、今回のプログラムの成果としてチャートを見守るのがしばらくの間は楽しみになりそうだ。

またPythonのディレクトリ構成についての記事を書き始めた。なんとなく構成は頭の中で出来上がった。

---緊急事態が宣言されてから深夜のパトロールが日課になっている。出歩く人は普段よりも当然すくなく、2,3人しかすれ違わない（だから2mルールも守ることができる）。 スーパーは、とうとうトイレットペーパーが深夜になっても在庫があった（当ブログは関係ないけれど、定番の生理用品は売り切れていた）。野菜類はだいたい残ってる。なぜか今日はしめじが売り切れていたから舞茸を買った。パスタはいまだに品切れ気味。納豆はまったく回復する見込みがない。納豆が恒常的に陳列されるようになると、すなわち今回の社会現象が次フェーズに突入したことを意味するだろう。

こんな定点観測をしているだけでも人生は面白い。誤解を恐れずに言えば、毎日がどんどん楽しくなっている、というのが実感だ。

2020年4月11日、土曜日。 『アメトーーク』におけるみちょぱについて女性ライターが色々書いていた。紹介するのは避けておくけれど、まあ怒りが尽きないんだろうなと感じた。「そんな振る舞いをしたら嫌われちゃうよ」と書いてるが、もっと端的に「みちょぱが嫌いだ」と書けばいいのに。

株プログラムはキャッシュをもたせる改修を行った。これで同一URLへのスクレイピングは一度だけに抑えることができて、負荷軽減・高速化を達成。これをライブラリとして使ったり、API化したりするのが次の目標になってきそう。

それとPythonについてはすこし振り返った結果、「最初からライブラリとして使えるように準備する」ってのが大切だと気づいた。これをテーマに記事を書いてみよう。

---夜は安売りしていたステーキ肉を焼いて食べつつ、『ドリームマッチ』を観る。芸人自身が（震えながらも）楽しんでいるのが本当にいいし、この番組の復活を祝いたい。岩井・直美コンビがすごいハネていて、配偶者が一番ハマっていた。個人的にはサンド富澤の凄さにちょっと引いた一夜だった。 本当のドリームは、来年、再来年と、ずっと楽しみに待ち続けよう。

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をやりなおそうか。