久々に東京に向かった

そして一泊して帰ってきた。

最近縁がなかったデレパ公録に当たってたので、一路東京まで。新幹線が着いてから気が付いたけど、東京駅より品川で降りた方が早かったし、なんなら新横浜から都立大学駅まで向かった方が早かったのではという疑惑が生じていて、やっぱり惰性はいかん、下調べはちゃんとせんといかんという気持ちになりました。デレパ公録自体はとってもデレパで非常に楽しかったです。本編で流れるだろうから、細かい話はなし。ライブパート書き残しておくなら、

  • ガレージロックことデレぱにぱにっク、面白すぎて早く音源欲しい。
  • Never say never出だしが少し遅れたのでイヤモニなしを確信。多分歓声で音が聞きづらかったのだろう。曲の後になるほどのっていってた。
  • オレサファ、ぴょこぴょこしないダンスだったが、あれを一人でやりきった深川芹亜すごい。
  • いとしーさーソロ、何人ぐらいめされたのだろうか……
  • Treasure☆、助けに来たと思ったらどっかに飛ばされた。また戻ってきた。おかしいな5thあんなに感動したのに、やっぱり面白曲なのでは?

宿は巣鴨。久々にきたけどあんまり変わっておらず、近々盆踊りでもやるのか提灯とやぐらっぽいのが設置されていた。そして今回はiPad Proと外付けキーボードのセットでどれくらいいけるか試してみる、という目標もあったので早速設置。

今日の構成はiPad proとキーボードなんだがホテルの無線LANがあんまり良くないので、USB-Cのハブを介してLANアダプターかまして有線接続している

タイトル通り、USB-CのハブとLANアダプターも持ってきてたので有線接続も試してみた。

Apple iPad?Pro (11インチ, Wi-Fi, 64GB) - スペースグレイ (最新モデル)

Apple iPad?Pro (11インチ, Wi-Fi, 64GB) - スペースグレイ (最新モデル)

  • 折りたたみ式エルゴノミクスキーボード、やはり初めはキーボードサイズや感触になれなくてミスタッチが多かった。じきになれたが……
  • 机の位置が重要ということがよくわかった。今回のホテル、iPadを置いた所の下が冷蔵庫になっていて前かがみになってキーボードを打つ形になり、辛かった。
  • 有線接続、最初は成功していたのだが、風呂に入るのにちょっと離れたらiPadから反応しなくなっていた。原因がよくわからず。

概ね体験は良かったけど、無線LANが調子悪いホテルだと辛いなぁという気持ちになった。

そして、今日はポタフェスに行った……けど、あまりに人が多く目当てのイヤホンの試聴も20分待ってできなかったので、一旦フロアをみて回ってからその足でeイヤホン秋葉原店に。……目当てのものあるじゃん。

greenfunding.jp

あんまり時間もなかったので、いくつか曲をピックアップして聞いてみたけど、音楽を聞くということに関してはCR-M1の方が気持ちよかったけど、音が見えてくる感はCR-V1の方がよかったなぁと思った。使った音源が圧縮音源なので、リップした音だとまた違うだろうからちょっと悩むなぁ。しばらく悩もう。

Effective Devops読み終わったー

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

raydive.hatenablog.jp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次は親知らず🦷か……

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

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

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章からは実装の話に移る。

*1:Sagasと呼ばれる

Alt MacBook Pro充電環境を揃える

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

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

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

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

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

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

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

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のリストを持つとか考えれば良さそうだが。