ライヴ・フィルム『ロジャー・ウォーターズ US + THEM』

www.110107.com

これを書いてるのが12月も後半といったところなので、もうすぐ1ヶ月ぐらい前になってしまうのだが見てきたことを残しておく。特定の強い動機があったわけでなく、たまたまネットでやるのを見かけて、しかもその日限りということでなんとなくチケットの抽選に申し込んでみたら当たってしまったのだが。まあ、色々音楽を聴いている中で、Pink Floyd、ロジャー・ウォーターズにあんまり触れてこなかったなと思っていたので、ちょうどいい機会だったのだ。

ありがたいことにすでにSpotifyでセットリストが公開されていたり、Youtubeに観客が撮影したライブがちょいちょい上がってるのでどんな雰囲気だったのかは確認できる。

ロジャー・ウォーターズが活動を始めた1960年代の音楽はよく聴いているほうだと思うのだが、ライブでここまで自身の思想を行き渡らせた物を映像等で見たことあるか、と言われるとおそらくないだろう。それほど昨今の世界状況について警鐘を鳴らしたいという思想が滲み出た、悪く言えば説教くさいと言われてしまうようなライブだった。もちろん、ライブとしての質は最高であった。The Dark side of the moonを中心にして、様々なPink floydの曲と自身の曲でライブのコンセプトを組み上げていた。The greate gig in the skyなど震えるほど美しかったし、真似したくなるMoneyのベースフレーズも聞けた。ラストのEclipseまでの流れはやっぱりアルバムで聴いたとき同様の感動もあった。映像含めて構成はしっかりしていて、エスタブリッシュメントに対する批判がよくわかるような内容だったなぁと思う。色々楽しめたはず。

Dark Side of the Moon

炎‾あなたがここにいてほしい‾

Wall (Remastered Discovery Edition)

Animals - 1st

話変わって、この映画見た後に改めてThe dark side of the moonをまるっと聴いてみたが、これがなんかスッと入ってきて。さっき「色々楽しめたはず」とは書いたが、同じ曲でもライブだとかなり刺々しく感じたのはなんでだろなとしばし考えていたのだが、コンセプトとして全く違うこともあるのだろうが、なんとなくロジャーウォーターズだけではやっぱりものたりなさがあるんじゃなかろうかと。そんなことをRun devil runでギターを弾いてるギルモアのことを、頭の片隅にうっすら思い浮かべながら考えていたのでした。

www.youtube.com

Run Devil Run by PAUL MCCARTNEY (2011-08-23)

失敗から学ぶRDBの正しい歩き方 読了

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

ここ最近、SQLクエリの書き換えやチューニングしたりしていたので、何か新しい観点を得られるかなと手にとってみた。

実はSQLアンチパターンはすでに読了済みなので、どうだろうと思っていたがアンチパターンでも出てきた内容の復習にもなり、新しい視点も得られたと思う。

SQLアンチパターン

raydive.hatenablog.jp

個人的にグッときたのは、

• 失われた事実
• 効かないINDEX
• フラグの闇
• ソートの依存
• 複雑なクエリ
• 塩漬けのバージョン
• フレームワーク依存症

と言ったところだろうか。特に「失われた事実」で履歴データがない事による弊害や「効かないINDEX」「ソートの依存」のところは現在進行形で考えなきゃいけないところなだけに、どういう観点を持って改善していこうかと参考になるなーと読んでいた。また「フラグの闇」で出てくる「状態を持たずに事実のみを格納する」、この観点は自分の中になく、発見であった。これはDBの設計だけじゃなくてそれこそソフトウェアアーキテクチャのお話だとEvent Sourcingなどにも通づるところがあるなと。「複雑なクエリ」についてはSQLアンチパターンでも印象に残っていた箇所なだけに、なるべくシンプルなSQLを書いていきたいなという気持ちを新たにした。バージョンアップについては……うん、ちゃんとしていきたいね。

全体的に読みやすく参考文献もSQLアンチパターンを筆頭にいくつもあげられており、もしデータベースであまり性能が出ていないとか改善が必要ならばまずこの本を手にとってみるのがいいかもしれない。

Pixel 3a impression

store.google.com

先月、FOMA携帯からPixel3aに端末を買い換えた。

さーすがーに寿命か

見ての通り、少しばかり携帯電話のバッテリーが膨らんでおりこりゃいかんと思っていろいろ検討した結果、

• この回線は家族との通話ぐらいしか使ってないのでそこまで通信が発生しない
• iPhoneも持っていてBiglobe SIM入れてる
• しばらくAndroid端末が手元にないので、ちょっと触ってみたい
• とはいえそこまでの性能はいらない

ということで、FOMAからXiにして通信を抑えつつそこそこのAndroid端末を購入することにした。

Pixel3aを選んだのはGoogle謹製であるので、セキュリティとか考えるとアップデートも早かろうしお値段的にも普通の携帯電話+一万円ぐらいで購入できるので、ちょうどいい塩梅だったのが理由。実際に今日のAndroid10アップデートはPixelシリーズから配信ですしね。

japanese.engadget.com

機種変

そんな感じでとりあえず触った感触はこんな感じ。

• 端末が軽くて良い。iPhoneが無駄に重い気がするので、もうちょっとなんとかしてほしいよなー
• レスポンスは早い、ただ個人的にはあんまり心地の良いレスポンスの早さじゃないかな
• OS全般的な操作体系はiPhoneXあたりと似通っていて、あまり混乱はない
  • 戻るボタンが小さくて最初気がつかなかったよ……
• Chromeの操作体系がiOSのと違ってて、タブ移動するときに画面上部を押さないといけないのはめんどくさい
  • iOSでSafariもChromeも画面下部にあるので、単純にiOSの作法に合わせてるんかな
• 自社のアプリ入れてしばらく操作してみたけど、画像添付しようとしてどこからやるのか一瞬わからなかった
  • これはアプリが悪いのか、それともOSのUIがわかりづらいのかわからんが……

とはいえ、そもそも電話ぐらいしか使わないのでXi回線になって親との通話がだいぶクリアになったのは良いですね。カメラあたりはそこまで使い込んでないので、もうちょっと使って楽しんでみるかなー。

Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンスのメモ書き #mixleap #gendadeddd

yahoo-osaka.connpass.com

最近社内のドメイン駆動開発系の読書会を二つ掛け持ちしてる人です。東京で同じカンファレンスがあって行きたかったなーと思ってたところ、大阪でもやると知って思わず登録、行ってきました。

raydive.hatenablog.jp

本当にどの発表も面白く、泥臭さとそれでもやりきる話ばかりでとても共感と気づきが得られたのはよかった。惜しむらくは、下にメモ書きした発表の裏で行われていたハンズオンや見られなかった発表などが多く、それらの内容も聴きたかった。ワークショップの内容はbiglobe-isp/workshopmobile: DDD ワークショップ課題のパブリックリポジトリで公開されていたので、これを社内でモデリングしてコードに落としてみるとかやってみるのもいいかなーと思ったりしている。他にもいくつかやってみたいことを思いついたので、どこかにメモっておこう。

OP

• 経産省のDXのレポート
  • 変更が容易でないので大変なことになる
  • DDDでこれらの課題に立ち向かっていく
• ❎綺麗な理論 ⭕現場のドロドロ感

ドメイン駆動設計という設計スタイル

• 増田 亨
• 基調講演
• 現場でやってることのっこだわりポイント
• 設計スタイルの選択
  • 関心の分離は原則、でもどうやる？
    • 入出力かドメインロジックか => トランザクションスクリプトかドメインオブジェクトモデルか => 入出力の設計が全体構造を左右するかドメインロジックの設計と実装が全体構造を左右するか
  • モジュール構造の考え方 プログラムの単位でどう作る？
  • 20:80の捉え方（パレードの法則）どこを頑張るか
  • ビジネスルールに基づく計算と判断のロジック、ビジネスルールに登場する値の種類に注目して独自の型を定義してロジック整理<=ここが大事
  • ここができてなかったら納期を遅らせても……バトルは起きる
• ドメインロジックに焦点を合わせる
  • ドメインオブジェクトモデルの周りにトランザクションスクリプトのようなものを並べる => 割とめんくさいことはある（インピーダンスミスマッチはある）
    • でも手間はかけてもやる価値はある
  • 実践：ドメイン知識を学び続ける、コード表現の継続的な改善（エヴァンス📙に書いてあるやつ）
  • 増田さんの現場ではドメイン知識、ドメインロジックという言葉は使ってない -> ビジネスルール、ビジネスロジック
  • ビジネスロジックはビジネスルールに基づく計算と判断のロジック
  • ビジネスルールはビジネス活動を制約し促進する決め事
    • 非常に曖昧な論理的でないもの、過去の意思決定の積み重ね、通過点
    • わかりみしかない
  • 変更容易性という言葉の違和感
    • バラした方があとで組み立てやすいぐらい
  • ドメイン知識を広げる
    • 要求の意味がわかる
    • 関係性や構造が見える
      • エンジニア的に納得感がある
    • 補完力と提案力がます
      • ドメインエキスパートからは出てこない！関心がない！
    • 時間とともに変化し続ける => 学び続ける必要
    • 最近機能ベースでしか考えられてないんじゃないかと、自社を振り返って思う
• 開発環境での実験結果と考察
  • コード書かない人
    • 書かない人の関心の文脈で見せる、丸っと理解させるのは無理
  • どの程度入出力にドメインの型が出てくるか
• ビジネスルールの基礎知識
  • 文書化されたビジネスルール
  • 顧客の利益 vs 自社の利益
  • 競争戦略とビジネスルール
  • ビジネスルールの階層構造
  • これらはドメイン層のパッケージ構造の設計
• コードで表現する基本テクニック
  • Fact, Rule, Goal
  • 独自の型を定義する
    • 納期の日付なのか、キャンセル可能な日付なのかなど
  • Domain modeling made functionalではOOなDDDでは…みたいなことを書いてあったが、増田さんが行き着いた先はだいたい同じような気がする
  • 暗黙的なif文 -> java enumを使ったコードに帰る -> ぎこちなくなったらリファクタリング、区分ごとのロジックを集める

DDDのモデリングとは何なのか、そしてどうコードに落とすのか

• 松岡 幸一郎
• モデリングをどうやるのか
• DDDでのモデリングとは
  • DomainLanguage.com
  • 問題解決のために物事の特定の側面を抽象化したもの
• ドメインモデル:ドメインの問題を解決するためのモデル
• データモデル：データベースに何か永続化するためのモデル
  • DDDでは両方出てくる
• 方法
  • 決まったものはない
  • ユースケース図/ドメインモデル図での例
• なぜユースケース図？
  • 具体化・言語化したい（どこまでしたいかなど）
• ドメインモデル図
  • クラス図の簡易版
  • 集約の範囲
  • 結構シンプル
• まずは一人の人がモデリングを作ってみて横展開するのがおすすめ、形から入っていく
  • これはそうかも、わかりやすい
• 属性のみの定義（ドメイン知識ない状態）からリファクタリングしていく
• スライド参照
• アプリ層にあるロジックをドメイン層に持っていくようにする
  • 順繰りにやっていく感じ
  • 繰り返しのリファクタリングが前提となってるので、良さげ
• setterをなくす、コンストラクタしか通らないことを保証する
• 抽象化の成功
• 現場での実践
  • お手本コードを作る
  • お手本に倣ってコードを書くようにチーム展開する
  • 軽量DDDでOK
  • 慣れたらドメインモデリングしてみる
  • ドメインモデル図を元にリファクタリングしていく
• 原理からよりお手本からの方が難度が低い、イメージしやすい
  • これは大事
• ORMはオブジェクトとテーブルが1:1になってるのはおすすめしない
  • わかるわ
• モデリングの時間は30分ぐらいが限度
• 集約とDBトランザクションはやってみて色々変えていく必要ある
• トランザクションの管理は実践DDDでトランザクションをチェック
• EntityからRepository呼ぶのはあんまりよくない

現場でドメイン駆動設計を広げるには何をすれば良いか？

• 安西 剛
• BIGLOBEでやってきたことの話
• ディスカッションしながらやる
• 安西さんのストーリー
  • 2010年、BIGLOBEは丸投げの会社 元請けに投げる人たち
  • 内政でWeb開発
  • アジャイル・スクラムを必死に勉強 => ちゃんとリリースした！
  • 巻き込んで文化が変わる
  • 設計できない独自言語による実装 ナニモワカラナイ
  • DDDが良いらしい => 増田さんを読んでみた（期待はしてなかった、大企業でやってくれたらラッキーぐらい）
  • 増田さん「やる気あるんだと驚いた」
  • プロジェクトを勝手に立ち上げ、1回目は失敗
  • 2回目でリリース
    • なんで許されたんだろう、1回目で失敗したらやめろと言われそうなものだが
    • 懇親会で聞こうと思ったが、聞けず……残念
  • 技術的負債が根深いところだったけど、広がっていった
  • 無視される、理解されない、反対される
  • 仲間を見つめて一歩一歩進めていった
• 自分のストーリーが大切
• 誰もやってない
  • 一人でやる
  • 勝手にプロダクトコードに入れる
    • 強い
• 仲間を選択する
  • わからない人は巻き込まない
• 広げる
  • 勉強会を行う
  • 上司を味方につける
  • 有識者に教えをこう
  • 自然と組織で公認となる
• チームから組織
  • いきなり全体でやらない
  • 暖簾分け方式
  • 失敗しても影響の少ないところから
  • 組織の２割の人数を目指す
• コードに対するアプローチ
  • 整理整頓する、分ける、名前をつける
• リファクタリング
  • 増田さんClean codeみたいなこといってる
• 動かないと始まらない
• 現場によって答えが違う
  • うちだとどうすべきか？

抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート

• ほげさん
• 突然のDDDチーム
  • 大変そう
  • 何させたがってるかわからない -> 抵抗感
• 「君のDomain層からは業務を感じない」
• 名詞を探す
  • ドメイン知識?
  • データの箱になった
• ドメインがスカスカ -> 集めてくる
• 処理順とか条件分岐とかDB更新がドメインだと思っていた
  • 絵から読み取れない情報が多い
  • やっぱりあかん
• ドメインだと思っていたものがドメインじゃなかった気づき
• 動詞を探す
  • 同じこといってる人いた気がする
  • dmmfだとワークフローとかそういうのかな？
    • イベントか、コトだ
• 境界を決める
  • Domainあった外の都合を排除
  • 知りすぎてるドメインを切断
  • 変わりやすい方に依存している線を逆にした
• 理解
  • モデリングするとER図ができる
    • Domain -> infraへの依存関係がある、よろしくない
    • 変更頻度が違う
• コードからここまでたどり着くのすごい
• テストコードは必要か？
  • ほげさんは必要派
  • コンパイルで見つからないバグはある
  • テストコードが最初のドメインの利用者
• システムのエラーとビジネスのエラーは分けたい
  • インフラで起きたエラーがドメインに伝搬してきた場合とかどうする？
  • ドメイン層でリポジトリのメソッド呼び出すとかしない方がいいか
• エヴァンス本ほとんど読んでない
  • コードからやっていった

過去の失敗例から再考するモデル駆動設計

• かとじゅんさん
• チケット料金モデリングは社内でやってみてもよいかも
• 軽量DDDの鋼材
  • トランザクションスクリプト亜種
  • ユビキタス言語を共有したつもり
    • 外向けの通訳が必要になった
    • 分析と実装の単一モデルになる前提じゃなかった
      • エンティティはテーブルではない……が勘違い
      • ドメインモデル貧血症
        • 合計金額の計算が外に出てる……
    • うちは軽量DDDだなぁ……戦術的パターンを適用しただけ
  • アプリケーションサービスは進行役（by 増田さん）
  • 無駄に英語使うより日本語使った方がわかる
  • まとまってないといけないものが、テーブルの都合で分けられる😨
  • getterしかないオブジェクト、辛い
• 言語とモデルを作ってソフトウェアに反映する
  • スライド参照
  • 自分たちは自分たちが作ってるものの使い方や意味を知っているのだろうか
• 分析から実装に反映、分析を見直し、要件を見直し。行ったり来たりする。
• ドメインモデル貧血症対策
  • オブジェクトは自己防衛する、不正な値は扱わない
  • コレクション型はそのままつかない、ドメイン固有型を介して使う
    • List<CartItem>にしがち -> CartItemsにする
  • 値オブジェクトのまま比較や計算ができるようにする
• スケーラブルな設計
  • ドメインオブジェクトと言語の体系が一致してる
  • ドメインの上の値はただのプリミティブ型ではない、制限などルールとそれに基づく計算能力を持つものである
    • dmmfだとこの部分を型に集約させている
• 集約の境界定義の善し悪し
  • スライド参照
    • 全部集約にするのか、集約は一つなのか
  • 全てが集約だと→アプリケーションサービスで悪いことに
    • アプリケーションサービスにドメインの知識が流れ出てくる
    • 試行錯誤してやってみたが結果整合性で不整合な状態が観測できる ->　ビジネス的な要件でダメだった
    • 集約は一つに
  • 細かく分けすぎると貧血症になりやすい
  • ユースケースだけでは境界定義が決まらない
  • でかいとI/Oのレイテンシがでかい
    • そもそも説明が難しいモデルは実装が大きくなる、I/0のコストもでかくなる
  • 振る舞いにフォーカスし小さい主役を実現するには、クエリ責務を他に考える CQRS
  • Event Storming + 値オブジェクトモデリング
• PDR
  • PDCAは工場の歩留まりをあげるためのもの

親知らず抜いて12日目

切ったところはもう赤みも見えなくなってきたので、あとは抜いたところの穴がふさがったり骨が回復したりするのを待つ感じ。口内炎の方はまだ腫れてる。こっちも小さくなってきてるので、土日で気にならなくなってくれたらいいんだけどなー。

UHA味覚糖 デンタクリア タブレット 口内菌ケア ヨーグルト味 スタンドパウチ 21粒

【Amazon.co.jp限定】[医薬部外品]システマ ハグキプラス デンタルリンス 900ml おまけつき

mrasu.hatenablog.jp

午前中リモートワークしながらテック記事あさってたら、面白いのを見つけた。この辺の話参考になる。

親知らず抜いて11日目

鏡で見てみるとちょっと小さくなったか。まだちょい動かした時の違和感が大きいが、まあこの辺口内炎になった時は似たような感じで治っていったから、もうちょいかかりそう。

UHA味覚糖 デンタクリア タブレット 口内菌ケア ヨーグルト味 スタンドパウチ 21粒

【Amazon.co.jp限定】[医薬部外品]システマ ハグキプラス デンタルリンス 900ml おまけつき

歯を磨く時に気を使わなくてよくなってきたので、だいぶ口内衛生もよくなってるだろうと思うが地道にやってく。

親知らず抜いて十日目

あらためて鏡で患部見てみると切ったところはちょっと赤くなって治りかけみたいな感じだが、ほおの部分が完全に口内炎になっていてそらひどいって言われるわと思った。なるべく患部に当たらないように、片側の歯でかんで食事してたから気づいてなかった。そんな部分もちょっと昨日より小さくなっているようなので、このままちゃんと治ればよろしいな。

それにしても台風めんどくさくてやだなぁ……って感じで、影響ないとよいですよね。

UHA味覚糖 デンタクリア タブレット 口内菌ケア ヨーグルト味 スタンドパウチ 21粒

【Amazon.co.jp限定】[医薬部外品]システマ ハグキプラス デンタルリンス 900ml おまけつき