nakanishy

250205

11 min read

意識

  • 最終的な結果ではなく、今日という日の学び・成長を楽しむ
    • 「問題」は見方を変えると楽しいものに変わったり成長の機会になったりする
    • 自分のものの見方に気をつけよう
      • 「より肯定的に捉えられないか？」
    • 「しなければいけない」という緊張感よりも、「今日も解くべき課題があって素晴らしい」という気楽なところ
  • わからなくなったり、頭が混乱するようなときは、一度立ち止まって、問題から離れてみること
    • 落ち着いて、自分がわかること、確実なことから少しずつ積み上げて考えていけばいい
    • 迷路の入口で失敗を恐れて立ち止まっていては何も始まらない
      • ハズレの道を引くこともあるが、ハズレの道はそこがハズレだと教えてくれる
      • それはつまり、別の道を試す必要がある、ということだ
      • そうして失敗の中で様々な道を探していると「これだ！」という道が感覚的に見つかる
    • 本を読んでいて、頭の中が知識が埋め尽くされそうになったときも、一度本を閉じて、重要そうなところを自分の頭で考え直してみることだ

やりたいこと

  • SQLite の FTS で AND OR NOT や部分一致を使った検のパフォーマンスを調べる

学び

  • CQRS
    • Command Query Responsibility Segregation
    • コマンドクエリ責務分離
    • Command (書き込み) と Query (読み取り) を別々のデータソースに分離する
    • そうすることで、書き込み、読み込みそれぞれに特化した設計や実装、最適化などが行える
    • 知識としてはわかったけど体感としてはいまいちピンときてない
  • 参考

DDD

  • もっとシンプルに捉えたい

    • 本質はきっととてもシンプルなことだ
    • 既存の技術の観点で捉えるのではなく、技術から離れたもっと中核の概念的なコア部分がある
    • それは、業務がどのように行われるのか、あるいはどのようなルールで運用されるのか、それを表す抽象的なモデル
    • そのコアの部分は図や文章で説明できる

  • プログラミング言語でどうモデルを表現するのかというのはまた別のスキル

  • おそらくエンジニアは技術的なことを頭の中から一旦排除したうえで、モデルの設計をする必要がある

  • その「設計」とはソフトウェアの設計ではなくモデルの設計

    • それは技術的なことは一切出てこない、純粋な業務の仕組みやルールの話

  • 業務をモデリングできたら、それを「ソフトウェアの設計」に落とし込む

  • 純粋なモデルとソフトウェアの実装の間には技術的な都合のようなものが挟まってくる

  • そういう技術的な都合を吸収するためにレイヤーが分かれている、と理解するとわかりやすいかもしれない

  • まだ実践をしたことがないからわからないけど、ドメインモデルは技術の都合を一切考えずに設計されるべきで、技術的な都合はドメインよりも外側で吸収されるべき、というのがシンプルでわかりやすい

    • また、エンジニアが考えるドメインモデル (クラスやインターフェースで表現されるもの) も技術的な制約を受けていることを理解する必要がある

  • つまり、オニオンアーキテクチャの図のさらに中心に、概念的なドメインモデルが存在していて、その外側にコード表現としてのドメインモデルがある、みたいな

  • この辺を実践の中で理解していきたいな

  • エンジニアが DDD を捉えようとするとき、技術的な観点からドメインモデルの設計をしようとしてしまうのが罠な気がした
    • つまり、クラスでどう表現されるかとか、技術的にどうするべきか、みたいなことをドメインのモデリングにいきなり持ち込もうとしてしまう
  • ドメインモデルは技術的なことを知らない人が見たり読んだりしても分かる形で表現されている必要がある
  • ソフトウェアとはそのモデルの一つの解決策にすぎない
  • 例えば、純粋なドメインモデルは、それを人力でやっても成立するようなもの
    • そこにルールや制約や流れみたいなものが表現されてるから、人がやったっていいし、何なら将来的には AI に食わせたら自動でやってくれるようになるかもしれない
    • ドメインモデルはそういう風な、技術的なことを含まないものであるべき、という理解

練習してみる。今作ってるサンプルファインダーを例に

  • 検索クエリ
    • 検索クエリ は文字列で表現される
    • AND
      • スペースで区切ると AND で検索される
        • 例: foo bar は foo と bar が含まれるサンプルを返却
    • OR
      • or で区切ると前後の単語は OR で検索される
        • 例: foo or bar は foo または bar が含まれるサンプルを返却
      • 複数のワードを指定することができる
        • 例: foo or bar or baz
      • closed hihat のようなスペースを含む文字を OR 検索する場合 () で囲む
        • 例: (closed hihat or open hihat)
    • - で始まる単語は NOT で検索される
      • 例: -foo は foo が含まれないサンプルを返却
    • " で囲むと完全一致で検索される
      • 例: "foo bar" は foo bar が含まれるサンプルを返却
    • AND は部分一致で検索され、OR と NOT は完全一致で検索される (仕様は要検討)
      • 例: foo bar は foooo barrrr にもマッチ (部分一致)
      • 例: foo or bar は foooo barrrr にマッチしない
  • 検索
    • サンプル名 が 検索クエリ に合致する サンプル のリストを返却する
    • サンプル が含まれているフォルダ名も検索の対象とする
    • 大文字小文字は区別されない
  • サンプル名
    • サンプル のファイル名を サンプル名 とする
    • サンプル名 はスペースで区切られた単語のリストとして扱う
    • ハイフンやアンダースコアが含まれている場合はスペースとして扱う
      • 例: foo_bar_kick_01.wav は foo bar kick 01 を サンプル名 とする
    • また、サンプルがフォルダに格納されている場合、フォルダ名もサンプル名の一部として扱う
      • その際、フォルダの階層を示すスラッシュは名前として扱わない
      • 例: foo/bar/kick/01.wav は foo bar kick 01 を サンプル名 とする
  • サンプル
    • wav または mp3 形式の音声ファイルをサンプルとする
    • サンプル は ファイルパス、ファイル名、サンプル名 から構成される (WIP)
  • 風呂の中で考えていて思ったけど、ドメインモデルには「見えない依存」が存在しうる
  • もしドメインモデルが DB の構造に依存した設計をしているのであれば、コード上にはみえないが、そのモデルは DB に依存している
  • もしドメインモデルが、フロントエンドの仕様に都合の良い形になっているのであれば、そのモデルはフロントエンドに依存している

グラフビュー