これだけで何不自由なく仕事ができる。あとおそらく数ヶ月後の未来には。 Apple Vision Proを日常的に使い始めた。「日常的に」というのがとてもだいじで、デモを体験するとか、ちょっと借りてみるとかではなく、わざわざ大枚はたいてアメリカまで買いに行ったのはこれをやるためだった。はたして、これが普段使いのツールとして便利に、生活に馴染む時代はやってくるのだろうか？というのを見極めたい、とおもったからだ。 実際に作業環境として「空間コンピューティング」というやつを受け入れ始めると、AppleとMetaの違い、Vision ProとQuestの設計思想の違いがより際立って見えてくる。Vision Proの話を見聞きすると、だいたいセットで「それ、Quest3でも同じことができるんだけど」という話もついてくるんだけれども、同じようで、同じでないんだということがよくわかる。 Appleが作りた

こんな言葉を聞いたことあるだろうか。 「あの人は技術力が低い」 「あの人は技術力が高い優秀なエンジニアだ」 「あの人は偉いポジションにいるが技術力は低い」 「あの有名な人は，きっと技術力が高いから働いたら色々と学べそうだ」 ある人が言った。 「この会社の従業員は自分より技術力が低い。技術力が高い俺の言うことが正しい」 どうやらその人にとっては設計力含め幅広い技術的な知見を持っていることが技術力らしい。 だが，その人の技術力をプロダクトに適用している姿を見たことがない。その上での主張だった。 主張と行動が相反しているようだが，と尋ねると 「この会社のコードがクソだからだ。」 そして「一から作ればできる」「（業務での）決裁権を与えてくれればできる」 などという反応もあった。 普通に考えれば，ネゴシエーションを取りながらリーダーシップを発揮して進めるべきなのではないか。別にそこに決裁権も何も関係

CQRS（Command Query Responsibility Segregation、コマンド・クエリー責任分離）は、現代のアプリケーション設計において重要な役割を果たしているが、今回はよく議論になる一貫性・可用性・スケーラビリティについて書いてみよう。文章のみの説明なので、非常にイメージしづらいかもしれないけど。 一貫性と可用性の評価軸CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用し、書き込みモデルで一貫性を、読み込みモデルで可用性を重視することで、最適なバランスを見つけることを目指している。 一貫性への影響イベントソーシングを伴わないシンプルなCQRSでは、非CQRSベースのシステムと同

どんな強力なツールでもそうであるように、CQRS（Command Query Responsibility Segregation）は無料で使えるわけではない。CQRSにはコスト（手間という意味）が伴うが、その利点も多い。 従来のアーキテクチャより複雑だと批判されることもあるCQRS/ES（Event Sourcing）だが、実際にはシンプルに実装できる部分もある。 CQRSにおけるモデルの分割CQRSではシステムを分割し、書き込みモデルと読み込みモデルを独立させる。例えば、ホテルの部屋を予約するシステムを考えると、部屋を予約する・宿泊人数を変更する・予約をキャンセルするなどの行為は書き込みモデル（集約ルート）に該当し、顧客別予約・ホテル別予約などの情報は読み込みモデルになる。この分割により、各オブジェクトはより単純化されるが、システム全体としての複雑さは増す。これは、CQRSにおける重要

こんなつぶやきをしたので、「モジュラーモノリス」について考える。特にモジュール性について考えてみる。 以下の主張は、実際のプロジェクト/プロダクトにとって最適かどうかは、具体的なビジネス要件、チームのスキルセット、運用上の制約など、多くの要因に依存する。アーキテクチャは常にトレードオフがあり、一つの解決策が全てのシナリオに適用できるわけではないので、その点を考慮して読んでほしい。 マイクロサービスではなくモジュラーモノリスを選択した場合には、しばしば以下の利点が強調される。 ネットワーク通信: モジュラーモノリスは、マイクロサービスと異なり、ネットワークを介した通信が発生しないため、ネットワーク遅延や断絶、通信エラーなどの問題が生じにくくなる データ整合性: 分散システムでは、データの整合性を保つために複雑なトランザクション管理やデータ同期が必要になるが、モジュラーモノリスでは同じデータベ

※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします 時間とリソースは有限なので、選択と集中をどうするのかというテーマ。前回の記事もサブドメイン戦略の観点だったが、この記事はコアドメイン戦略に的を絞っている。 Nick Tuneさんの記事には、コアドメイン戦略のパターンが示されている。数が多いので重要そうなものだけをピックアップして紹介＆考察してみる。 Context Distillation(コンテキストの蒸留)According to this definition, a Core Domain is an area of the domain with the opportunity for high business differentiation. This represents a

DDD関連の記事を紹介してみたい。 今回は、Vladikkさんの2018年の記事。タイトルは「DDDの基本を再考する」だが、内容としては「サブドメインの分類方法」について述べられている。 今回はこの記事を要約してみよう。（日本語での要約の許可をVladikkさんからもらっています） ※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします 前段に書かれている内容は基本的なものだ。 ドメインが事業領域を意味する サブドメインはさらに細分化された事業領域 サブドメインには種類がある。 汎用サブドメイン 一般的な問題を解決することで、コアドメインと支援サブドメインをサポートする 支援サブドメイン コアドメインをサポートするためのサブドメイン コアドメイン 重要なビジネス価値を提供する。競争優位性を持つか

AndroidのためのJava/Kotlinはスコープ外とします まず断っておくと、俺はScalaが好きだ。 自分が作ったScalaプロダクトは二個現存している。うち一つはまだまだ自分が開発している。というか今は会社を作って1人でプロダクトを作っている身なのだが、それもScala3+ZIO2でゴリゴリ書いている。 でも残念、もうScalaというかJVM言語がオススメできません。TypeScriptかGoかRustをオススメします。 どういうこと？まずこの記事を見ていただくのが一番分かりやすい。 https://aws.amazon.com/jp/builders-flash/202310/java-serverless-saas-backend/?awsf.filter-name=*all 素晴らしいエントリーだ。読みに行かないせっかちな方のために概要を紹介する JavaプロダクトをAWS

チュートリアルでDDD体験: ドメインモデルの成長を紹介 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」 僕もこのドメインで振る舞い中心のモデリングをしてみた。実装は可能なモデルを書いてみましたが、今回は細かい実装の話はありません。 イベントを抽出まずイベント(起こった事実)から考えました。日々の勤怠で何が起きるのだろう。出勤したり退勤したり休憩したりと打刻するのは間違いない。システムが何か命令(コマンド)を受理したらこういうイベントが発生するはず。 「出勤した」イベントには、誰がいつ出勤したかを説明する事実が記載されている。「退勤した」や「休憩を開始した」や「休憩を終了した」なども同じ。あと、打刻間違いの修正もあるので「打刻を修正した」もある。ちょっと荒削りだがこんな印象。 出勤した 退勤した 休憩を開始した 休憩を終了した 打刻を修正した ちなみに