最近はあんまりああいう絵がないね。ちと寂しさがある。しかしもう七夕かー。
ぶたの人、ラテックスアレルギーの検査をする
個人的に面白い体験をしたので、日記として残しておこうと思う。
- 出版社/メーカー: デザインフィル
- メディア: オフィス用品
- この商品を含むブログを見る
近々、大学病院で局所麻酔をして親知らずを抜歯することになった。歯茎に埋没して横に生えているため、数年前から抜いたほうがいいですよと言われていたのだが、親知らずの前の歯に対して悪影響が出てきてしまったので観念して抜くことになったのだ。ほんとはもっと早く終わるはずだったのだけど、色々病院も大変のようだ………
問診を受ける過程でアレルギーはあるかと聞かれた。自分はこれといってダメなものとかないしなーと話してはいたのだが、メロンやキウイフルーツを食べて喉がイガイガすることはあるとぽろっというと、「手術で使うラテックスの入った手袋でアレルギーが発症するかもしれないので検査しましょう」と言われた。割とおおごとになっちゃったなぁと思ったが、病院としても事故は減らしたいのだろうと思って日取りと時間を決めて今日検査をしてもらった。
実際にどういう検査をするかというと、ラテックスのアレルゲンとなる成分をちくっと皮膚に注入してその状態を見るというものだ。説明を受けた際は単純にそれをやるだけだと思ったのだが、当日に受けた際には比較対象として水とヒスタミンを注入してどの程度腫れるかをチェックしていた。水は全く無反応なもの、ヒスタミンは必ず症状を引き起こすものとして、ラテックスがどの程度の状態になるかをチェックする。なるほど、比較対象としてはわかりやすい。ちなみにこの間はベッドの上で寝たままになっていて、ちくっと刺す瞬間とかは見えない。
結果としては特に問題なく、何も起こらなかった。検査を実施してくれた人の説明を聞いてると、「陰性の可能性が高い」みたいな言い方をしていたので後から症状でる人がいるかな、とか自分もそういう言い方するなぁとか思っていた。次に濡れた手袋を実際にはめてチェックするという検査も行った。これもラテックスが入っていないゴム手袋とラテックス入りの手袋で比較していた。なるほどねぇ。
バリアローブ ラテックス手袋 ハイグリップ パウダーフリー M 100枚入
- 出版社/メーカー: リーブル(リーブル)
- メディア: Tools & Hardware
- この商品を含むブログを見る
しばらく着けたのち、こちらも特に問題なく陰性の結果。さあこれであとは親知らずを抜くだけである。ああでも。
Domain modelling made functional Chapter 6, Chapter 7を読む
Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#
- 作者: Scott Wlaschin
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2018/02/04
- メディア: ペーパーバック
- この商品を含むブログを見る
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章からは実装の話に移る。
- 作者: Scott Wlaschin
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2018/02/27
- メディア: Kindle版
- この商品を含むブログを見る
![Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]](https://thumbnail.image.rakuten.co.jp/@0_mall/rakutenkobo-ebooks/cabinet/3271/2000006113271.jpg?_ex=128x128 "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
- メディア: エレクトロニクス
- この商品を含むブログを見る
CheeroのUSB-C PD充電アダプターが新しく出て、若干安くなってるのに気がついた。
たまーに会社のMacBook Proを持ち帰って仕事したりすることもあるけど、アダプタ類を持ち歩くのもめんどくさいなーと思ったりするので、この機会にサクッとUSB-CケーブルとUSB-Cハブも買っておくことにした。
Anker USB-C & USB-C Thunderbolt 3 ケーブル (50cm) 【PD対応 超高速 40Gbps 100W出力 USB2.0 / 3.0 / 3.1 対応】
- 出版社/メーカー: Anker
- メディア: Wireless Phone Accessory
- この商品を含むブログを見る
届いたので動作チェックしてみたが、今のところ問題なし。持ち歩くこと考えると、こっちの方が楽かもしれない。
Domain modelling made functional Chapter 4, Chapter 5 を読む
Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#
- 作者: Scott Wlaschin
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2018/02/04
- メディア: ペーパーバック
- この商品を含むブログを見る
ちょっと開いたけど、読んでいる。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のリストを持つとか考えれば良さそうだが。
- 作者: Scott Wlaschin
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2018/02/27
- メディア: Kindle版
- この商品を含むブログを見る
「【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践」を読んだ
【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
- 作者: 石原一宏,田中英和,田中真史
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2012/01/28
- メディア: 単行本
- 購入: 2人 クリック: 12回
- この商品を含むブログ (9件) を見る
最近他チームの手伝いでテスト作ったりしてるんだけど、今一度テストってどうやるんだけっけ？と思い購入。月一で書籍購入を会社でやってくれるのは本当にありがたい。
同値テスト、境界値、組み合わせテストなど、個々のテストについて作成の仕方を解説したり、もっと大枠の話としてテスト計画やテストの設計をどうしていくかなどが網羅的に書かれているなと感じた。内容的には知っていることも多く、忘れていたことをちゃんと呼び覚ましてくれたというところが大きいが、初めてテストに携わる人なんかはこれを読んで勉強するのも良いかと思う。特に組み合わせテストでのテスト項目の削減方法はきっちり知っておくといい。全ての組み合わせでテストするのは到底現実的でないので、いい落とし所を作るためにどうするか学べる。またこういうところはTDDやるときに、仕様からどういう値がありうるかなとか考えるときに役立つかな。
ただ記載のある内容は基本的に真面目にウォーターフォール開発でのテストを念頭に置いてるものなので、テスト計画のところはまあそういうこともあるよねぐらいの感覚で読んでおいたほうがいいかもしれない。現実的には無理くりやらないといけないこともあったりするのだ……うっ頭が……とはいえ、前々職で作っていたテストドキュメントなどはこういうのを元にして作ってるんだなという気づきがあった。以前読んだメルカリでのテスト管理ツールの選定に出てきたツールたちもこの辺りを念頭においたりしてるのだろうか。
あと、アジャイル的にやっているところとかだと、本に書いてあるように設計書が細かく分かれているとかない場合もあるから、そういうときにどうなるかなーというのは気になる。もちろんソフトウェアが満たさなければならない要求があるのだから、それをチェックするためのテストがあればいいのだけど必ずしも本書通りの形にはならなそう。継続したテスト、テストの自動化、などなど最近話題のところもあるけど、本書では範囲に入っていない。以下のリンクのように探索的テストが必要な場合もあるだろう。
ただテストする上での知識として何が必要かは、必要十分に詰まっていたと思う。割とさっくり読めるのでテストの手始めに読むのが良いと思った。
