@kotyのブログ

PythonとかAWSとか勉強会のこととかを、田舎者SEがつづります。記事のライセンスは"CC BY"でお願いします。

OAuth徹底入門 読了後メモ

仕事で必要になり手に取った。

入門といえば入門なんだろうか、徹底と言っているだけあって400ページ超と(お値段もそれなり)かなりのボリュームそして情報量であった。

OAuthに関する本はほとんど出回ってなくて同人誌くらいしかなかったんだけど、これはよくまとまっていた。OAuthを手がけるのであれば読んでおくべき良書だと思う。

ドメイン駆動設計入門 読了後メモ

来年度はスクラッチ開発が予定されているので、手に取った。ちなみにいわゆる「DDD本」は挫折して本棚でほこりをかぶっております。DDD本が出てから久しい。みんなこの程度の知識は持っているのだろうか。。。

主にRailsDjangoでも同じ話だな)での開発を念頭に読んで、気になった点を五月雨に書きます。

Chapter 2. 値オブジェクト

所感

静的型な処理系であれば誤った代入も防げるし、ロジックは集約できるし、価値は理解できるんだけど、ORMと相性が悪そうだなーとは思った。どうしてんだろうな。

Chapter 4. ドメインサービス

所感

各機能に必ずドメインサービスを作りましょうみたいなSIerな考え方だと小規模サービスではかなり窮屈で開発効率が悪くなりそう。 基本的にはモデルに業務ロジックを集約しつつ、モデルをまたがるような処理はドメインサービスに書くのが良さそう。

さすがにコントローラーに長大なロジックを書くことはないんだけど、モデルは大きくなりがちだと思う。理由としては以下が挙げられる。

  • DBの正規化が不足していてフィールドが多すぎる
  • モデルにまたがった処理が書かれている

後者の場合はドメインサービスの概念を導入してやるとうまくいくんでしょう。

「業務を表現したものではなく、アプリケーションを作るために必要なのであれば、アプリケーションサービスに書くべき」とのこと。メール送信とかはどうなんだろうな。

Chapter 5. リポジトリ

データの永続化を担当。

所感

Railsだとアクティブレコードがあるから不要なようにも思った。

Chapter 6. アプリケーションサービス

ユースケースを実現するためのもの。

所感

MVCアーキテクチャのコントローラーか、バッチ処理のエントリーポイントかな。

アプリケーションサービスがドメインの振る舞いを呼び出せてしまうと、各所にロジックが散らばってしまうので、データを詰め替えるべきとの主張だった。大規模アーキテクチャにありがちなルールだなぁ。

6.4. 凝集度

すべてのインスタンス変数はすべてのメソッドで使われるべき。一部のメソッドでしか使われない変数があるのであれば、クラスとして切り出すべき。

所感

あまり考えられていなかったので、意識したい。モデルやコントローラーのクラスは凝集度が低くなりがちだとは思う。

Chapter 7. 依存関係のコントロール

本来、DBアクセスなどの低レベルモジュールに高レベルモジュールが影響を受けるべきではない。永続化方法はドメインに関係がないはずである。インターフェースを宣言し、低レベルのモジュールはそのインターフェースに合わせて実装することで、依存関係を切り離すことができる。

ここで問題になるのが実装クラスをどうやって作るかだが、DI Containerを使うと良い。

所感

例示されたケースだと、リポジトリ入れ替え可能になるのでテストが楽になるよ、とのことだったが、Railsの場合は本物のDBに向かってテストを実行して大きな問題は感じていない。。。

Chapter 9. ファクトリ

ただ漫然とnewするのではなく、ファクトリを導入すべきか検討する習慣をつけるべき。

所感

これはまあおっしゃるとおりだと思った。

Chapter 12. 集約

集約の外部から教会の内部のオブジェクトを操作してはいけない。集約を操作するための直接のインターフェースとなるオブジェクトは集約ルート(Aggregate Root)と呼ばれるオブジェクトに限定される。

所感

自分の想像していた「集約」とは違った。集約ルートの考え方は良いと思った。ただの代入であっても、それにどんな業務的な意味があるのか、あるのであればメソッドにくくることを検討する習慣を持ちたい。

おしまい

Railsだったらどうするかなーと考えながら読んだ。大前提としてドメイン駆動設計をちゃんとやらなければいけないケースでは静的型が必要で、Railsドメイン駆動設計には不向きなんだろうと思う。

RubyPythonなどの動的型付け言語に慣れ切ってしまったところにこの本を読むと、静的型付け言語を使いこなす自信がなくなってくる。ある程度静的型付き言語に慣れた後に読み直すとまた感じ方が違うんだろう。

実際の開発では何らかのWebフレームワークやORMに乗ることになるので、そのフレームワーク流儀に従ったうえでDDDを適用していくんだろう。

ミル付きコーヒーメーカー所感

ふたつほど使ったことがあるので、突然ですが所感を書きます。私としては、このふたつなら手入れが楽なパナソニックの方をおすすめします。

シロカ

1年ほど使用。ステンレスフィルター。ガラス製サーバーを落として割ってしまい、スレンレス製サーバーにかえた。

長所

  • フィルターの在庫を気にする必要がない
  • 見た目がややおしゃれ

短所

  • スレンレスフィルターをよく洗うなど、毎回の部品洗浄が面倒
  • 連続して淹れるときは、洗った部品を拭いて乾かす必要がある

パナソニック

10年近く使用。ミルが動いた時に異音が出るようになって買い替えた。

長所

  • 掃除が楽。紙フィルターを捨てた後に軽く洗うだけ
  • ミル部分は自動洗浄されるため、毎回の掃除は不要

そういえば連続して淹れたい時はどうしてたかな、、、忘れてしまった。ミル部分を乾かしたりはしていなかったと思う。

短所

  • 紙フィルターの在庫を気にする必要がある

ミル稼働時の音

シロカの方が小さいような気がするけど、パナソニックの方も今は改良されているかもしれない。どっちにしても集合住宅で早朝深夜に動かすのはちゅうちょするレベルだと思う。

味はどうなのよ

どちらもうまいです。なお参考情報↓

失敗の科学 読了後メモ

やらかし反省シリーズ。やらかしに関係する本を手に取ってみたが、「やらかしをしないようにする」ではなく「やらかすのは仕方ない。それを今後に活かすことが大事」のような内容だった。

第1章 失敗のマネジメント

妻が医療事故により亡くなってしまった事例。

ミスの再発防止のための仕組みができておらず「調査嫌い」な医療業界と、第三者機関など再発防止の仕組みができている航空業界を(ふたつの業界に環境要因はあり必ずしも医療業界を責められないとフォローしつつ)比較している。そして「間違いを教えてくれるフィードバックがなければ、訓練や経験を何年積んでも何も向上しない」「フィードバックを得る環境を作るために『ミスの報告を処罰しない』」ことを説いている。

所感

  • 環境要因もあるとはいえ、医療業界の閉鎖性には暗い気持ちになった。日本だけじゃないんだな。
  • ミスの報告を責めないのは大事。障害票に「(直接の)障害起因者」欄を作るとか、障害件数ゼロを目標にする組織にいたことがあったけど、今はどうしてるかな。

第2章 人はウソを隠すのではなく信じ込む

人は自分の過ちを認めるよりも、事実の解釈を変えてしまう。 犯罪捜査にDNA鑑定が使われるまでは、捜査は人の記憶に頼っており多くの冤罪が生まれた。

所感

  • 自分が誤っていると分かったときは素直に認められるようでありたい。そうしているつもりだけど結構難しい

第3章 「単純化の罠」から脱出せよ

瀉血(しゃけつ)療法の事例、刑務所訪問の効果の事例などを挙げ、 人は物事を単純化しがちだし単純化されて理解しやすいものを信じやすい。 しかし物事はそれほど単純では無いことが多い。RCTなど客観的な事実をみることが大事と説く。

所感

第5章 「犯人探し」バイアスとの闘い

「非難したり訴えたり裁判にかけたりすれば、相手は責任感を強く持つようになると思い込んだままでいいのか、ということだ。今のところそれで説明責任が強化されたという証拠はひとつも出ていない」

所感

まったくそのとおり。。。

第6章 究極の成果をもたらすマインドセット

「個人でも組織でも、失敗に真正面から取り組めば成長できるが、逃げれば何も学べない」

所感

まったくそのとおり。。。

終章 失敗と人類の進化

「子どもたちの心に、失敗は恥ずかしいものでも汚らわしいものでもなく、学習の支えになるものだと刻み付けなければならない。」

所感

これは日々言っていきたい。

最後に

ということで、「やらかし」を気をつけはせよ恐れずに生きたいと思ったのだった。

私って、ADHD脳!? 読了後メモ

最近公私共に大きめの「やらかし」をしていたので、手に取った。何かを解決するわけではないけれど、これまで感じていた生きづらさの原因が見える化されて納得感(?)は得られた。

「片付けられない」以外は「注意力散漫」「忘れ物、失くし物が多い」「並行作業が苦手」「決まった手順に沿って作業するのが苦手」など心当たりがかなりあり、程度は分からんけど多少なりとも注意欠陥障害に該当するのだと思う。 これまでいろいろやらかしをしてきて、どうして自分は出来ないんだと悩むことがあったが、これも個性だと思って受け入れるしかないんだろう。 もちろん、やらかさないように努力できるところはしないといけないが。。。注意書きとか予定とか入れててもそもそも注意書きや予定をを見なかったりするんだよな。

それでも、周りにご迷惑をかけつつもここまで生きてこれたから、この先も何とかなるでしょう。

漫画で分かりやすいので、似たようなお悩みの方、うっかり者のフォローばかりしている方、おすすめです。

ローカルプロキシで、Chromeへのレスポンスを編集する(Mac OS BigSur)

やりたいこと

背景は聞かないでください。

  • 特定のサイトにアクセスした時に
  • 「本番サイトです!」とHTMLに表示

f:id:kkotyy:20210213203948p:plain

方針としては、ローカルプロキシを立てて特定のサイトの場合だけ当該プロキシを経由、プロキシでレスポンスを編集することを考えた。

ローカルプロキシ

GUIを備えたプロキシもあるようだが、導入がお手軽そうだったmitmproxyというのを使ってみた。

インストール

brew install mitmproxy

いったん起動する

mitmproxy

この状態で、プロキシ経由で証明書をダウンロードする

curl -x 127.0.0.1:8080 'http://mitm.it/cert/pem' > /tmp/mitm.pem

証明書をMacのKeyChainに登録し、Trustする。

タグ挿入スクリプト

BeautifulSoupを使うので入れておく。よく分からんがmitmproxy独自のpython仮想環境がある模様。

/usr/local/opt/mitmproxy/libexec/bin/pip install beautifulsoup4

pythonコードを書く。text/html のレスポンスにタグを挿入する。

import os
from bs4 import BeautifulSoup
from mitmproxy import http

class Injector:

    def response(self, flow: http.HTTPFlow) -> None:
        if flow.response.headers.get("content-type") and flow.response.headers.get("content-type").find("text/html") != -1:
            html = BeautifulSoup(flow.response.content, "html.parser")
            if html.body:
                tag = html.new_tag("span", id="mitmproxy", style="color: red;")
                tag.string = '本番サイトです!!!'
                html.body.insert(0, tag)
                flow.response.content = str(html).encode("utf8")
addons = [Injector()]

書いたスクリプトを指定して、起動しておく

mitmdump -s inject_alert.py

Chromeの設定

Chrome extensionをインストールする。 chrome.google.com

proxyの設定

f:id:kkotyy:20210213203631p:plain

auto switchの設定

f:id:kkotyy:20210213203729p:plain

最後に、extensionのアイコンから auto switch を選択する。

f:id:kkotyy:20210213203858p:plain

大成功の図

なんというか、そもそもこんなことをする必要に迫られたくない。

f:id:kkotyy:20210213203948p:plain

参考サイト

「モノリスからマイクロサービスへ」読了後メモ

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

  • 作者:Sam Newman
  • 発売日: 2020/12/26
  • メディア: 単行本(ソフトカバー)

  • マイクロサービスに分割されていることで、一部分だけ新しい技術で作り替えやすくなる。これは顧客にとって良い結果を提供する意外にも新しい技術を習得することで開発者の満足にもつながる。
  • 分解しやすさ、分解による利益の2軸で分解する機能の候補を絞る
  • 一発で分解するのではなく、段階的にリライトを繰り返す

4章の「データベースを分割する」ではデータベースリファクタリングで出てきた話題と割と共通していた。まずはトリガーやデータ更新時、日時バッチ等で新旧両方のDBに更新をかけ、徐々に切り離していくっていう辺りが。

トランザクションをかけられない場合にどうデータの整合性を維持するか

2フェーズコミット、オーケストレーションベースのサーガ、コレオグラフィベースのサーガなどが紹介されていたが、どれも私が関わっているシステムには過剰に感じた。保守できる気がしない。

ロールバック用のロジックを用意しておくのが現実的である。

マイクロサービス間の依存関係をどう管理していくか

現実のシステムでも徐々にシステム間連携が増えてきている。何らかの方法で依存関係を見える化しておかないと、ある改修が意図しない箇所に影響してしまうことが先々ありそうな気がする。 サービスメッシュてのが紹介されていたが、これがいいんだろうか。。。