Effective Devops読み終わったー

前々から社内と前職でやっていた読書会がやっと終わった。

raydive.hatenablog.jp

文化的に非難の応酬となるような組織では人は働きづらいし、組織・チーム・個人の価値観の認識があってないとうまくいかない。もちろん違いはあることは認め、そこからどうまとめていくか。はたまた合わない人は離れることを恐れてはいけないし、組織としても退場をお願いすることもある。書かれてる内容は至極まっとうな印象を受けていて、はじめに述べたとおりなかなか面白いなと思う。

Effective DevOpsを読んでいる - 日々の御伽噺

具体的にどうすればいいというよりは、もう少し理想的な状態とはこういうところだ、という書き方になっていて、実際に個々のケースについてどう解決するかはあなたが所属するチーム、組織によって異なると言いきっている。すぐに手を打てる手法を知りたい人にはあまり向いてない本だと思う。

Effective DevOpsを読んでいる - 日々の御伽噺

ここから9ヶ月たったのだが、このときからこの本の印象は変わらず。Devopsとはヒップなツールの扱いやこれで全てが解決する打ち出の小槌でもなく、継続的に改善と振り返りを行い人が協力し合う文化を育むものだというのがこの本の主張だと思う。最近ツール入れてもメンテされてないと意味ないよなーとか思うことも多く、結局のところ人を巻き込んで誰もがそれをやるという文化にならないと楽にならないよなぁという結論に達していて、行き着く先はやっぱりこの本と一緒なんだとつくづく思うのである。

反面、ベストプラクティスなるものについてはこの本ではほとんど書かれていない。実際にDevopsを推進している企業や団体の例は上がっているが、基本的にここではこういう例でうまくいったけどあなたのところではうまくいかないかもしれない、と直接的ではないにしろ繰り返し書かれている。つまりは自分たちで体験してやっていって、そこから徐々に広げていくしかない。本書中の言葉を借りるならストーリーから学んでナラティブを綴っていく。今いるところでそれがどこまでできるんだろうかと考えてしまうが、ひとまずは自分の周りからということになるかなぁ。

そういえばこういう読書会は初めて主催側にたったのだけど、反省点として一つあげると、うまく周りを巻き込めなかったことだ。本書の内容からすると、技術者だけでなくいろんな立場の人を巻き込んでいった方がよかったが、うまく取り込めずもっと身のあるものになっただろうと思うだけに、力不足を感じた。アピールできるようになろう。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps 4本柱による持続可能な組織文化の育て方 [ Jennifer Davis ]

また久々にとる出町枡方商店街の黒板

ふむ

最近はあんまりああいう絵がないね。ちと寂しさがある。しかしもう七夕かー。

ぶたの人、ラテックスアレルギーの検査をする

個人的に面白い体験をしたので、日記として残しておこうと思う。

ミドリ 日記 1日1ページ 洋風 12844006

近々、大学病院で局所麻酔をして親知らずを抜歯することになった。歯茎に埋没して横に生えているため、数年前から抜いたほうがいいですよと言われていたのだが、親知らずの前の歯に対して悪影響が出てきてしまったので観念して抜くことになったのだ。ほんとはもっと早く終わるはずだったのだけど、色々病院も大変のようだ………

問診を受ける過程でアレルギーはあるかと聞かれた。自分はこれといってダメなものとかないしなーと話してはいたのだが、メロンやキウイフルーツを食べて喉がイガイガすることはあるとぽろっというと、「手術で使うラテックスの入った手袋でアレルギーが発症するかもしれないので検査しましょう」と言われた。割とおおごとになっちゃったなぁと思ったが、病院としても事故は減らしたいのだろうと思って日取りと時間を決めて今日検査をしてもらった。

実際にどういう検査をするかというと、ラテックスのアレルゲンとなる成分をちくっと皮膚に注入してその状態を見るというものだ。説明を受けた際は単純にそれをやるだけだと思ったのだが、当日に受けた際には比較対象として水とヒスタミンを注入してどの程度腫れるかをチェックしていた。水は全く無反応なもの、ヒスタミンは必ず症状を引き起こすものとして、ラテックスがどの程度の状態になるかをチェックする。なるほど、比較対象としてはわかりやすい。ちなみにこの間はベッドの上で寝たままになっていて、ちくっと刺す瞬間とかは見えない。

結果としては特に問題なく、何も起こらなかった。検査を実施してくれた人の説明を聞いてると、「陰性の可能性が高い」みたいな言い方をしていたので後から症状でる人がいるかな、とか自分もそういう言い方するなぁとか思っていた。次に濡れた手袋を実際にはめてチェックするという検査も行った。これもラテックスが入っていないゴム手袋とラテックス入りの手袋で比較していた。なるほどねぇ。

バリアローブ ラテックス手袋 ハイグリップ パウダーフリー M 100枚入

しばらく着けたのち、こちらも特に問題なく陰性の結果。さあこれであとは親知らずを抜くだけである。ああでも。

次は親知らず🦷か……

Domain modelling made functional Chapter 6, Chapter 7を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

6章では集約などの一貫性をどう表すか、を重点に置いて話を進めていっている。ここでも型として表現していくことを徹底している。例えばビジネスルール上で「顧客はemailか住所を持っていなければならない」とした時に、どう表現するか？ この本の回答はこうだ。

• emailのみの情報を表現する型
• 住所のみの情報を表現する型
• emailと住所の情報を表現する型

これらの型の'OR' Typeが顧客が持つ情報であるとしている。こうすることによって、ドメイン上でありえない状態に陥ることがなくなる。型で表現することによって、そもそもillegalなことを表現させなくするという観点は非常に面白いし、自分の頭からは抜け落ちていた観点だったと気付かされた。

またDDDの文脈でよく出てくる集約の一貫性の話、単一の集約や複数の集約間の整合性はどうするかなども書かれているが、やはり基本として「1集約に1トランザクション」「結果整合性」という話になる。この部分はまあそうだよねという気持ち。

7章はワークフローをパイプライン処理できるよう個々の関数に落とし込んでいく。入力であるCommandをGenericsを用いて表現したり、MQに単一のCommandだけでなく複数のCommandが入る場合は型としてどう表現するかなど、見所は多い。が、ここではこれまで定義してきたそれぞれのOrderを状態として捉える、UnvalidatedOrderが処理されることでValidatedOrderになりまたそれが処理されPriceOrderになる、一連の流れを状態の変化として考えることが重要な点だろう。型によってState Machineを表現することによって、抜け漏れなくある状態である動作を行うことができるようになる。実際にどでかい状態遷移図で悩まされたことのある自分にとっては、ありがたさがよくわかった。

後半では、副作用を表現していったり長期間にわたるワークフロー*1についても書かれている。副作用を型として表現する話は過去にScalaMatsuriで聞いていたのですんなりと納得できた。本書中の例としても途中のValidationを行う関数がリモートサービスを呼び出しているので、それを呼び出してる関数もreturnとしてはAsyncResultにならないといけない、とわかりやすい。Sagasは最初さらっと読んでいたが、今考えてみればAkkaなんかを使う局面と考えても良さそうだ。

ここまでで、一旦モデリングは終わり。8章からは実装の話に移る。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)

Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]

*1:Sagasと呼ばれる

Alt MacBook Pro充電環境を揃える

cheero USB-C PD Charger 60W (White + Silver)

CheeroのUSB-C PD充電アダプターが新しく出て、若干安くなってるのに気がついた。

たまーに会社のMacBook Proを持ち帰って仕事したりすることもあるけど、アダプタ類を持ち歩くのもめんどくさいなーと思ったりするので、この機会にサクッとUSB-CケーブルとUSB-Cハブも買っておくことにした。

Anker 7-in-1 プレミアム USB-Cハブ (100WPD出力対応)【2つのUSB-Cポート / 100W出力 Power Delivery 対応USB-Cポート / 4K対応HDMI出力ポート / 2つのUSB-Aポート / MicroSD&SDカードスロット搭載】MacBook Pro 2017 / 2018、ChromeBook他対応

Anker USB-C & USB-C Thunderbolt 3 ケーブル (50cm) 【PD対応 超高速 40Gbps 100W出力 USB2.0 / 3.0 / 3.1 対応】

届いたので動作チェックしてみたが、今のところ問題なし。持ち歩くこと考えると、こっちの方が楽かもしれない。

Domain modelling made functional Chapter 4, Chapter 5 を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

ちょっと開いたけど、読んでいる。Chapter 4がF#での型システムの話、そしてChapter 5がそれを踏まえてOrderTakingSystemを型で表していくという流れ。

DDDでモデリングしていった結果、Value ObjectやEntity、Aggregateを発見していくけど、それらを型として定義してWorkflowをそれらの型の変換という形に落とし込んでいく。型として表す、それ自体はDDDにおいて大事な話だと思うが、Workflowを型として表していくのは実はしっくりくるのではないかと思った。実際にValue ObjectやEntityに属しないけど必要なビジネスロジックなどは存在するので、それらはServiceとして表したりするのだけど、データとしての型とそれらを変換する関数として定義するとそういう違いもなくなるなと。個人的にはChapter3あたりと違って、腑に落ちる内容が多かったかな。

読書会内ではOR typeをScalaで表現するとなると、case classが頻出してちょっと記述がめんどいなどの話や、AggregateであるOrderに含まれるEntityのIDのみを持つのかそのEntity自体を持つのか、その判断はどうやって決めるのかなどが上がっていた。Aggregateに他のEntityそのものを持たせるかは、基本的に疎結合強凝縮を意識してモデリングしていけばいいのかなと考えていて、今回の例だとそのドメイン上で扱うにはOrderからOrderLineのリストが辿れるようにしておく、CustomerはIDのみ持つは一つの解かな。詳細でRDBに保存するにしても、ドメイン上ではそれが置いておくのが吉となりそう。もちろん実装上OrderLineが膨大に持つことになってメモリを圧迫するとかなってしまうと、IDのリストを持つとか考えれば良さそうだが。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)

Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]

「【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践」を読んだ

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

最近他チームの手伝いでテスト作ったりしてるんだけど、今一度テストってどうやるんだけっけ？と思い購入。月一で書籍購入を会社でやってくれるのは本当にありがたい。

同値テスト、境界値、組み合わせテストなど、個々のテストについて作成の仕方を解説したり、もっと大枠の話としてテスト計画やテストの設計をどうしていくかなどが網羅的に書かれているなと感じた。内容的には知っていることも多く、忘れていたことをちゃんと呼び覚ましてくれたというところが大きいが、初めてテストに携わる人なんかはこれを読んで勉強するのも良いかと思う。特に組み合わせテストでのテスト項目の削減方法はきっちり知っておくといい。全ての組み合わせでテストするのは到底現実的でないので、いい落とし所を作るためにどうするか学べる。またこういうところはTDDやるときに、仕様からどういう値がありうるかなとか考えるときに役立つかな。

ただ記載のある内容は基本的に真面目にウォーターフォール開発でのテストを念頭に置いてるものなので、テスト計画のところはまあそういうこともあるよねぐらいの感覚で読んでおいたほうがいいかもしれない。現実的には無理くりやらないといけないこともあったりするのだ……うっ頭が……とはいえ、前々職で作っていたテストドキュメントなどはこういうのを元にして作ってるんだなという気づきがあった。以前読んだメルカリでのテスト管理ツールの選定に出てきたツールたちもこの辺りを念頭においたりしてるのだろうか。

tech.mercari.com

あと、アジャイル的にやっているところとかだと、本に書いてあるように設計書が細かく分かれているとかない場合もあるから、そういうときにどうなるかなーというのは気になる。もちろんソフトウェアが満たさなければならない要求があるのだから、それをチェックするためのテストがあればいいのだけど必ずしも本書通りの形にはならなそう。継続したテスト、テストの自動化、などなど最近話題のところもあるけど、本書では範囲に入っていない。以下のリンクのように探索的テストが必要な場合もあるだろう。

codezine.jp

ただテストする上での知識として何が必要かは、必要十分に詰まっていたと思う。割とさっくり読めるのでテストの手始めに読むのが良いと思った。