こんな感じで、良いことが多ければ良いですね。本年もよろしくお願いいたします。
紛れもないThe Whoのアルバム「WHO」
Youtubeでスタジオ風景をとった映像が公式で出てたことに気がついたり、なんか新作が出ると聴いたのがつい最近のような気がしてたが、発売日をしばらくすぎてからもう手に入ることに気がついた程度にはここ最近のThe Who情報に疎かったりする。が、Apple Musicで聴いてみたらこれがなんともThe Whoのアルバムという感じで、嬉しくなってすぐAmazonでCDを注文してしまった。ここ最近は通勤のローテーションに入れているが、ほんとにお気に入りで、彼らが頻繁にアルバムを出していた60年、70年代と同じくエネルギッシュで気を抜いたら崩れてしまいそうな繊細さを持ち合わせた音を今になって聴けるのは本当に喜ばしい。オリジナルメンバーはもう二人しかいなくなってしばらく経つのに、ここまでThe Whoなアルバムに仕上がっていて傑作だと思う。もちろん、ドラムとかベースの質感はキースやジョンと違うのだけれども、バンドとして合わさったときのマジックはまだまだ生きていて、凄まじいなと感じる。
個人的には四曲目のDetour*1が、見事にボ・ディドリーのリズムで大変お気に入りなんだが、ボーナストラックに入っているGot Nothing To ProveがQuick oneかSell outに入ってそうな雰囲気の曲で、このアルバム単体で全てのThe Whoがやってきたことをまるっと詰め込んだお得感がある。ロックでもポップスでもミニオペラでもなんでもやってきた奴らだ。
特にYoutubeで先行して発表されてたAll This Music Must Fadeを聞くと、The kids are alrightから何から何までThe Whoなんだよね。泣きそう。
一方でShe rocked my worldみたいなこれまでなかったような曲調もあり、多分自分はこのやってきたこととこれからのThe Whoをみずみずしく感じるのが好きなんだろうな。年齢を感じさせずに、でも経験がなければここまでの素晴らしい音になっていない。一度でも生でライブをみたいなと思ってしまうのはわがままだろうか。The Kinks共々お願いしたい。
ライヴ・フィルム『ロジャー・ウォーターズ US + THEM』
これを書いてるのが12月も後半といったところなので、もうすぐ1ヶ月ぐらい前になってしまうのだが見てきたことを残しておく。特定の強い動機があったわけでなく、たまたまネットでやるのを見かけて、しかもその日限りということでなんとなくチケットの抽選に申し込んでみたら当たってしまったのだが。まあ、色々音楽を聴いている中で、Pink Floyd、ロジャー・ウォーターズにあんまり触れてこなかったなと思っていたので、ちょうどいい機会だったのだ。
ありがたいことにすでにSpotifyでセットリストが公開されていたり、Youtubeに観客が撮影したライブがちょいちょい上がってるのでどんな雰囲気だったのかは確認できる。
ロジャー・ウォーターズが活動を始めた1960年代の音楽はよく聴いているほうだと思うのだが、ライブでここまで自身の思想を行き渡らせた物を映像等で見たことあるか、と言われるとおそらくないだろう。それほど昨今の世界状況について警鐘を鳴らしたいという思想が滲み出た、悪く言えば説教くさいと言われてしまうようなライブだった。もちろん、ライブとしての質は最高であった。The Dark side of the moonを中心にして、様々なPink floydの曲と自身の曲でライブのコンセプトを組み上げていた。The greate gig in the skyなど震えるほど美しかったし、真似したくなるMoneyのベースフレーズも聞けた。ラストのEclipseまでの流れはやっぱりアルバムで聴いたとき同様の感動もあった。映像含めて構成はしっかりしていて、エスタブリッシュメントに対する批判がよくわかるような内容だったなぁと思う。色々楽しめたはず。
- アーティスト:Pink Floyd
- 出版社/メーカー: Parlophone (Wea)
- 発売日: 2011/09/26
- メディア: CD
- アーティスト:ピンク・フロイド
- 出版社/メーカー: EMIミュージック・ジャパン
- 発売日: 2006/09/06
- メディア: CD
Wall (Remastered Discovery Edition)
- アーティスト:Pink Floyd
- 出版社/メーカー: Parlophone (Wea)
- 発売日: 2011/09/26
- メディア: CD
- アーティスト:Pink Floyd
- 出版社/メーカー: Harvest
- メディア: LP Record
話変わって、この映画見た後に改めてThe dark side of the moonをまるっと聴いてみたが、これがなんかスッと入ってきて。さっき「色々楽しめたはず」とは書いたが、同じ曲でもライブだとかなり刺々しく感じたのはなんでだろなとしばし考えていたのだが、コンセプトとして全く違うこともあるのだろうが、なんとなくロジャーウォーターズだけではやっぱりものたりなさがあるんじゃなかろうかと。そんなことをRun devil runでギターを弾いてるギルモアのことを、頭の片隅にうっすら思い浮かべながら考えていたのでした。
Run Devil Run by PAUL MCCARTNEY (2011-08-23)
- アーティスト:PAUL MCCARTNEY
- 出版社/メーカー: Universal Japan
- メディア: CD
失敗から学ぶRDBの正しい歩き方 読了
失敗から学ぶRDBの正しい歩き方 (Software Design plus)
- 作者: 曽根壮大
- 出版社/メーカー: 技術評論社
- 発売日: 2019/03/06
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
ここ最近、SQLクエリの書き換えやチューニングしたりしていたので、何か新しい観点を得られるかなと手にとってみた。
実はSQLアンチパターンはすでに読了済みなので、どうだろうと思っていたがアンチパターンでも出てきた内容の復習にもなり、新しい視点も得られたと思う。
- 作者: Bill Karwin,和田卓人,和田省二,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
- 購入: 9人 クリック: 698回
- この商品を含むブログ (46件) を見る
個人的にグッときたのは、
- 失われた事実
- 効かないINDEX
- フラグの闇
- ソートの依存
- 複雑なクエリ
- 塩漬けのバージョン
- フレームワーク依存症
と言ったところだろうか。特に「失われた事実」で履歴データがない事による弊害や「効かないINDEX」「ソートの依存」のところは現在進行形で考えなきゃいけないところなだけに、どういう観点を持って改善していこうかと参考になるなーと読んでいた。また「フラグの闇」で出てくる「状態を持たずに事実のみを格納する」、この観点は自分の中になく、発見であった。これはDBの設計だけじゃなくてそれこそソフトウェアアーキテクチャのお話だとEvent Sourcingなどにも通づるところがあるなと。「複雑なクエリ」についてはSQLアンチパターンでも印象に残っていた箇所なだけに、なるべくシンプルなSQLを書いていきたいなという気持ちを新たにした。バージョンアップについては……うん、ちゃんとしていきたいね。
全体的に読みやすく参考文献もSQLアンチパターンを筆頭にいくつもあげられており、もしデータベースであまり性能が出ていないとか改善が必要ならばまずこの本を手にとってみるのがいいかもしれない。
Pixel 3a impression
先月、FOMA携帯からPixel3aに端末を買い換えた。
見ての通り、少しばかり携帯電話のバッテリーが膨らんでおりこりゃいかんと思っていろいろ検討した結果、
- この回線は家族との通話ぐらいしか使ってないのでそこまで通信が発生しない
- iPhoneも持っていてBiglobe SIM入れてる
- しばらくAndroid端末が手元にないので、ちょっと触ってみたい
- とはいえそこまでの性能はいらない
ということで、FOMAからXiにして通信を抑えつつそこそこのAndroid端末を購入することにした。
Pixel3aを選んだのはGoogle謹製であるので、セキュリティとか考えるとアップデートも早かろうしお値段的にも普通の携帯電話+一万円ぐらいで購入できるので、ちょうどいい塩梅だったのが理由。実際に今日のAndroid10アップデートはPixelシリーズから配信ですしね。
そんな感じでとりあえず触った感触はこんな感じ。
- 端末が軽くて良い。iPhoneが無駄に重い気がするので、もうちょっとなんとかしてほしいよなー
- レスポンスは早い、ただ個人的にはあんまり心地の良いレスポンスの早さじゃないかな
- OS全般的な操作体系はiPhoneXあたりと似通っていて、あまり混乱はない
- 戻るボタンが小さくて最初気がつかなかったよ……
- Chromeの操作体系がiOSのと違ってて、タブ移動するときに画面上部を押さないといけないのはめんどくさい
- 自社のアプリ入れてしばらく操作してみたけど、画像添付しようとしてどこからやるのか一瞬わからなかった
- これはアプリが悪いのか、それともOSのUIがわかりづらいのかわからんが……
とはいえ、そもそも電話ぐらいしか使わないのでXi回線になって親との通話がだいぶクリアになったのは良いですね。カメラあたりはそこまで使い込んでないので、もうちょっと使って楽しんでみるかなー。
Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンスのメモ書き #mixleap #gendadeddd
最近社内のドメイン駆動開発系の読書会を二つ掛け持ちしてる人です。東京で同じカンファレンスがあって行きたかったなーと思ってたところ、大阪でもやると知って思わず登録、行ってきました。
本当にどの発表も面白く、泥臭さとそれでもやりきる話ばかりでとても共感と気づきが得られたのはよかった。惜しむらくは、下にメモ書きした発表の裏で行われていたハンズオンや見られなかった発表などが多く、それらの内容も聴きたかった。ワークショップの内容はbiglobe-isp/workshopmobile: DDD ワークショップ課題のパブリックリポジトリで公開されていたので、これを社内でモデリングしてコードに落としてみるとかやってみるのもいいかなーと思ったりしている。他にもいくつかやってみたいことを思いついたので、どこかにメモっておこう。
OP
- 経産省のDXのレポート
- 変更が容易でないので大変なことになる
- DDDでこれらの課題に立ち向かっていく
- ❎綺麗な理論 ⭕現場のドロドロ感
ドメイン駆動設計という設計スタイル
- 増田 亨
- 基調講演
- 現場でやってることのっこだわりポイント
- 設計スタイルの選択
- ドメインロジックに焦点を合わせる
- ドメインオブジェクトモデルの周りにトランザクションスクリプトのようなものを並べる => 割とめんくさいことはある(インピーダンスミスマッチはある)
- でも手間はかけてもやる価値はある
- 実践:ドメイン知識を学び続ける、コード表現の継続的な改善(エヴァンス📙に書いてあるやつ)
- 増田さんの現場ではドメイン知識、ドメインロジックという言葉は使ってない -> ビジネスルール、ビジネスロジック
- ビジネスロジックはビジネスルールに基づく計算と判断のロジック
- ビジネスルールはビジネス活動を制約し促進する決め事
- 非常に曖昧な論理的でないもの、過去の意思決定の積み重ね、通過点
- わかりみしかない
- 変更容易性という言葉の違和感
- バラした方があとで組み立てやすいぐらい
- ドメイン知識を広げる
- 要求の意味がわかる
- 関係性や構造が見える
- エンジニア的に納得感がある
- 補完力と提案力がます
- ドメインエキスパートからは出てこない!関心がない!
- 時間とともに変化し続ける => 学び続ける必要
- 最近機能ベースでしか考えられてないんじゃないかと、自社を振り返って思う
- ドメインオブジェクトモデルの周りにトランザクションスクリプトのようなものを並べる => 割とめんくさいことはある(インピーダンスミスマッチはある)
- 開発環境での実験結果と考察
- コード書かない人
- 書かない人の関心の文脈で見せる、丸っと理解させるのは無理
- どの程度入出力にドメインの型が出てくるか
- コード書かない人
- ビジネスルールの基礎知識
- 文書化されたビジネスルール
- 顧客の利益 vs 自社の利益
- 競争戦略とビジネスルール
- ビジネスルールの階層構造
- これらはドメイン層のパッケージ構造の設計
- コードで表現する基本テクニック
DDDのモデリングとは何なのか、そしてどうコードに落とすのか
- 松岡 幸一郎
- モデリングをどうやるのか
- DDDでのモデリングとは
- DomainLanguage.com
- 問題解決のために物事の特定の側面を抽象化したもの
- ドメインモデル:ドメインの問題を解決するためのモデル
- データモデル:データベースに何か永続化するためのモデル
- DDDでは両方出てくる
- 方法
- なぜユースケース図?
- 具体化・言語化したい(どこまでしたいかなど)
- ドメインモデル図
- クラス図の簡易版
- 集約の範囲
- 結構シンプル
- まずは一人の人がモデリングを作ってみて横展開するのがおすすめ、形から入っていく
- これはそうかも、わかりやすい
- 属性のみの定義(ドメイン知識ない状態)からリファクタリングしていく
- スライド参照
- アプリ層にあるロジックをドメイン層に持っていくようにする
- 順繰りにやっていく感じ
- 繰り返しのリファクタリングが前提となってるので、良さげ
- setterをなくす、コンストラクタしか通らないことを保証する
- 抽象化の成功
- 現場での実践
- 原理からよりお手本からの方が難度が低い、イメージしやすい
- これは大事
- ORMはオブジェクトとテーブルが1:1になってるのはおすすめしない
- わかるわ
- モデリングの時間は30分ぐらいが限度
- 集約とDBトランザクションはやってみて色々変えていく必要ある
- トランザクションの管理は実践DDDでトランザクションをチェック
- EntityからRepository呼ぶのはあんまりよくない
現場でドメイン駆動設計を広げるには何をすれば良いか?
- 安西 剛
- BIGLOBEでやってきたことの話
- ディスカッションしながらやる
- 安西さんのストーリー
- 2010年、BIGLOBEは丸投げの会社 元請けに投げる人たち
- 内政でWeb開発
- アジャイル・スクラムを必死に勉強 => ちゃんとリリースした!
- 巻き込んで文化が変わる
- 設計できない独自言語による実装 ナニモワカラナイ
- DDDが良いらしい => 増田さんを読んでみた(期待はしてなかった、大企業でやってくれたらラッキーぐらい)
- 増田さん「やる気あるんだと驚いた」
- プロジェクトを勝手に立ち上げ、1回目は失敗
- 2回目でリリース
- なんで許されたんだろう、1回目で失敗したらやめろと言われそうなものだが
- 懇親会で聞こうと思ったが、聞けず……残念
- 技術的負債が根深いところだったけど、広がっていった
- 無視される、理解されない、反対される
- 仲間を見つめて一歩一歩進めていった
- 自分のストーリーが大切
- 誰もやってない
- 一人でやる
- 勝手にプロダクトコードに入れる
- 強い
- 仲間を選択する
- わからない人は巻き込まない
- 広げる
- 勉強会を行う
- 上司を味方につける
- 有識者に教えをこう
- 自然と組織で公認となる
- チームから組織
- いきなり全体でやらない
- 暖簾分け方式
- 失敗しても影響の少ないところから
- 組織の2割の人数を目指す
- コードに対するアプローチ
- 整理整頓する、分ける、名前をつける
- リファクタリング
- 増田さんClean codeみたいなこといってる
- 動かないと始まらない
- 現場によって答えが違う
- うちだとどうすべきか?
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
- ほげさん
- 突然のDDDチーム
- 大変そう
- 何させたがってるかわからない -> 抵抗感
- 「君のDomain層からは業務を感じない」
- 名詞を探す
- ドメイン知識?
- データの箱になった
- ドメインがスカスカ -> 集めてくる
- 処理順とか条件分岐とかDB更新がドメインだと思っていた
- 絵から読み取れない情報が多い
- やっぱりあかん
- ドメインだと思っていたものがドメインじゃなかった気づき
- 動詞を探す
- 同じこといってる人いた気がする
- dmmfだとワークフローとかそういうのかな?
- イベントか、コトだ
- 境界を決める
- Domainあった外の都合を排除
- 知りすぎてるドメインを切断
- 変わりやすい方に依存している線を逆にした
- 理解
- モデリングするとER図ができる
- Domain -> infraへの依存関係がある、よろしくない
- 変更頻度が違う
- モデリングするとER図ができる
- コードからここまでたどり着くのすごい
- テストコードは必要か?
- システムのエラーとビジネスのエラーは分けたい
- エヴァンス本ほとんど読んでない
- コードからやっていった
過去の失敗例から再考するモデル駆動設計
- かとじゅんさん
- チケット料金モデリングは社内でやってみてもよいかも
- 軽量DDDの鋼材
- 言語とモデルを作ってソフトウェアに反映する
- スライド参照
- 自分たちは自分たちが作ってるものの使い方や意味を知っているのだろうか
- 分析から実装に反映、分析を見直し、要件を見直し。行ったり来たりする。
- ドメインモデル貧血症対策
- オブジェクトは自己防衛する、不正な値は扱わない
- コレクション型はそのままつかない、ドメイン固有型を介して使う
List<CartItem>
にしがち ->CartItems
にする
- 値オブジェクトのまま比較や計算ができるようにする
- スケーラブルな設計
- 集約の境界定義の善し悪し
- スライド参照
- 全部集約にするのか、集約は一つなのか
- 全てが集約だと→アプリケーションサービスで悪いことに
- アプリケーションサービスにドメインの知識が流れ出てくる
- 試行錯誤してやってみたが結果整合性で不整合な状態が観測できる -> ビジネス的な要件でダメだった
- 集約は一つに
- 細かく分けすぎると貧血症になりやすい
- ユースケースだけでは境界定義が決まらない
- でかいとI/Oのレイテンシがでかい
- そもそも説明が難しいモデルは実装が大きくなる、I/0のコストもでかくなる
- 振る舞いにフォーカスし小さい主役を実現するには、クエリ責務を他に考える CQRS
- Event Storming + 値オブジェクトモデリング
- スライド参照
- PDR
- PDCAは工場の歩留まりをあげるためのもの