連休の余韻も楽しんだので今日から散歩を再開した。ちょっと前までは「陽の光を浴びなきゃ！」と思って3時過ぎにウロウロしてたけど、これからはもうちょっと涼しい時間帯がいいなと思って、夕暮れ時に散歩しながら fukabori.fm を聴いてた。Value Object のお話。面白いなぁ 73. Value Object w/ kumagi | fukabori.fm kumagi さんの記事はこちら Value Objectについて整理しよう - Software Transactional Memo お絵描き PoEAA や DDD はだいぶ前に読んだことがあるけど、Value Object を雰囲気で捉えてるからちゃんと見直しておこうと思って、調べたりしながら絵を描いた。こういうことなのかな？ （絵をかくほどでもなかった・・・ Value Object とは？ kumagi さんも書いてる

最近DDDや値オブジェクトやドメインオブジェクトの定義が一部界隈で話題です。kumagi sanとかとじゅんさんの間で熱い議論が何日にも渡って繰り広げられています。 kumagi.hatenablog.com blog.j5ik2o.me kumagi.hatenablog.com kumagiさん眠たいんですが…。続きは明日でもいいですか。 — かとじゅん (@j5ik2o) 2022年5月19日 大変ですね！ ぼくも違うチャネルでkumagi sanに色々理解をぶつけてみたものの全然違うようで色々と教えてもらったりしました。 しかしながら、これ実際どこでどう使うのかなと。大先生がこんな事を言ってました。 言葉遊びしてるんじゃねえんだぞ、動くものを作れ — Yoshi Yamaguchi (@ymotongpoo) 2022年5月19日 というわけで、最近書いたコードを題材にちょっとリフ

「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と

今も熱い牛丼談義が続いている。僕も自転車置場で牛丼はつゆだくがうまいとか、卵は半熟か生かどうかとか話すのは大好きだ。僕は最近、大盛りを食べるのはちょっときつくなってきた。それはともかく、せっかくだから僕もバリューオブジェクトの天下一牛丼談義に参戦しよう。 天下一牛丼談義への参戦のきっかけは、かとじゅんさんがバリューオブジェクトはドメイン固有型の一種であるという解釈を記事で紹介していて、それは違うんじゃないかと思ってtweetをしたことだ。これにはかとじゅんさんから回答をもらうことができた。しかし、まだいくつかの疑問が残っているので、ドメイン固有型とドメインオブジェクトとはなにかという議論を通じて、バリューオブジェクトと不変条件、そしてバリューオブジェクトとは結局は何であるのかというのを、ここで整理していきたい。 バリューオブジェクトはドメイン固有の型なのか？ドメイン固有型(値オブジェクト含

blog.j5ik2o.me この記事は彼のブログ投稿への返信です。 彼とのtwitter上でのreplyの応酬スレッドが見返すと引くほど長くなっていたので僕の観点からの要約を纏める。予め断っておくとこれは本当に自転車置き場の議論以外の何物でもなく、技術的な学びはどこにもない不毛なやりとりであって、苦労して理解する価値がなかったなどの苦情は受け付けない。 kumagi: 値オブジェクトはIDによらない等価比較をするオブジェクトの事であって、ドメイン固有の値オブジェクトもそうでない値オブジェクトもある。 かとじゅん: それはおかしい。全ての値オブジェクトは何らかのドメインオブジェクトの一部であって、Integerすらも整数ドメインの問題を解決するために設計されたドメインオブジェクトと言える。Evansも肯定しているはずだ。 kumagi: なるほど、その整理の中で逆にドメインオブジェクトでな

kumagi.hatenablog.com こちらの記事への反応です。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない RubyのHash、Pythonのdict、C++のstd::unordered_setは、アプリケーションのドメインからみるとインフラストラクチャに見えるかもしれません。 しかし、RubyのHash、Pythonのdict、C++のstd::unordered_set であっても、解決する問題領域(ドメイン)があります。なので、そのドメインにとっては、ドメイン固有型(=ドメインオブジェクト)である、と解釈しています。(ドメイン固有型の”固有”が紛らわしかったかもしれません

blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ

Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜

みなさんもそろそろ牛丼に飽きて、海鮮丼が食べたくなった頃だろうか？ もらえるかはわからないけれどアンサーソングを待たずに、個人的なメモだと書いてある記事に言及するのは無粋かもしれない。しかし、どうしても気になってしまい見過ごせない記述があったのでこれを書くことにした。 気になったのは Learning Domain-Driven Design のバリューオブジェクトについての要約部分についてだ。 かとじゅんさんは同書の Chapter 6. Tackling Complex Business Logic をもとに、次のような感想を書いている。 値オブジェクトは振る舞いとデータを含むドメインモデル(ドメインオブジェクト)である、と示されている まず気になるのが、ドメインモデルとドメインオブジェクトが同一であるかのような記述だ。しかし、ドメインオブジェクト(Domain Object) という

この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし

NTT Communications の社内ランチ勉強会 (TechLunch) で講演した資料です。

近年、RailsアプリにService Objectを追加するメリットを説く記事が次から次へと量産されています。私は本記事において、それがなぜ正しくないかを述べたいと思う次第であります。もっとよい方法はあるのです。 私はこれまで、Service Objectに関するネット上の議論にときおり参加しては、問題に対するまっとうな解決方法としてService Objectが正しくない理由について繰り返し見解を述べてきました。実際、私は多くの場合においてService Objectよりもっとよい解決方法があると考えるのみならず、Service Objectはオブジェクト指向設計原則への配慮が損なわれている兆候を示すアンチパターンとして取り扱っています。 このような深遠なポイントを細切れのツイートやコメント欄を追って理解するのは大変です。そこで私は、私の見解を正確に表すいくつかの現実的なコードを詳しく

はじめに TechTrainでエンジニアをしているスーです。 Twitterはこちらで、DMなど気軽にしてもらって大丈夫です！ 今回はTechTrainバックエンドの開発環境を紹介します。 開発全体について気になるのであれば、TechTrain技術スタック紹介と作り手としての市場に思うことを見ていただけますと嬉しいです！ バックエンドの開発環境前提 以前紹介した際からバージョンをしっかり上げました。 現在は、Laravel:9.x (PHP:8.1.x)を利用しています。 現状はDocker, Docker Compose, ECSを利用しています。 環境構築 Makefileを使いながら、M1 MacもIntelMacもコマンド一発で環境構築が終わるようにしています。 ここが結構メンテナンスが難しいところではありますが、常に更新を行なっています。 一発で立ち上がるところはこだわりの一つで

技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。アクセンチュア株式会社、マネジング・ディレクターの水上廣敏氏は、エンジニアを5つのタイプに分類する「エンジニア占い」を用いて、それぞれのキャリアについて発表しました。全3回。1回目は、自身の生い立ちと、エンジニア占いの4つの質問について。 小学校4年生ぐらいの時からBASIC言語の勉強を始めた 水上廣敏氏（以下、水上）：それではさっそく始めたいと思います。エンジニアと一言で言ってもさまざまな職種やタイプがあるかなと思うのですが、この時間は「エンジニア占い」と題して、思い切って5つに絞って、それぞれのキャリアがどうなりそうかを占えたらおもしろいなと思って用意してきました。よろしくお願いします。 始める前に、まず自己紹介を簡単にしていきたいと思います。私は、アクセンチュアの水上と申し

Software Design (ソフトウェアデザイン) 2022年06月号の「後悔しないAWSデータベースの選び方 RDSとDynamoDB，使い分けのポイントを徹底解説」について AWSRDSnosqlDynamoDBAurora 初めに TwitterのDB界隈で少し話題になっていた特集の記事について、個人的に気になった指摘事項の一覧です。 記事自体は限られた紙面数で簡潔に読みやすくまとまっており、特にAurora/RDSについては要注意なポイントについてもまとめられていてわかりやすいものでした。 しかしながら、私知識と経験の範囲内での判断で、説明不足や技術的に誤解を招く表現等が見られたのでまとめてみます。 ※執筆者は普段の業務も忙しい中で限られた時間、紙面数で対象読者に向けて記事をまとめるので必死でしたでしょうし、どんな人でもどうしても経験や知識の範囲は限られてしまうことから、誰も

はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな

anond.hatelabo.jp 誰か教えてくれ。 「体育の授業に球技を入れることに何の価値があるのか」ってことを 私はけっこう運動してきた人間で、だいたいの球技は人並み以上にできたりするのだけど、なぜか体育嫌いの巣窟であるhatenaにいるのではてな民のために運動について語っていきたい。 学校の授業に球技を入れることの意味について増田は疑問を呈しているけれど、球技以外で子供がやって楽しい集団スポーツを上げるとなるとかなり難しいと思うぞ。 球を使わない集団スポーツって実はかなり少なかったりする。体育の授業で行える球技ではない集団スポーツってダンス、綱引き、騎馬戦、団体行動、縄跳びぐらいじゃないかな。柔道や空手のチーム戦もあるけど今のご時世ケガしたら保護者からクレームがくるので無理だと思う。設備があればボートや自転車も楽しいけれど費用がかかるので一般的ではない。 となると何も設備がなくても

１．色々な職場を渡り歩いて 15年ぐらいソフトウェア開発の業界にいます。 グローバル企業、大企業、中小企業までいろいろなサイズの現場で手伝いをしたことがあります。 ゆく先々で、"戦力外通告"をされる人をみてきました。 派遣やフリーランスなら契約解除です。 正社員で解雇される人はあまりみたことはないですが、自分から退職エージェントを雇って辞めた人は見たことあります。 僕が見た人は、企業サイドから辞めてほしい人なのになぜ、エージェント雇うんだろうと思うような感じでしたが。 ちなみに、記事のタイトルに「生まれる」と書いたのは、次の理由からです。 雇用関係は、雇い主と労働者の双方向であり、状況もまた一方的にできるものではなく、双方の問題で生じると思うので、「生まれる」という表現にしました。 ２．"戦力外通告"をされる人の特徴 いろいろなパターンがあると思いますが、私が実際に見てきた人の特徴を書いて

アジャイルとは、トライアンドエラーを効果的に行うための知識群、だと思う トライアンドエラーするのはどういうときかというと、やってみないと分からないとき やってみないと分からないときはどういうときかというと、その時点での能力を超えた仕事をするとき 能力を超えた仕事をするとき、成功が目的であることに変わりは無いけど、計画と実行よりも学習と軌道修正が重要になる 最初に立てた計画は間違っているため プロダクト開発の領域は大雑把には、ディスカバリーとデリバリーに分けられる ディスカバリーにおいて十分な能力を有している=つくるべき正しいものを見極められている場合、ディスカバリーにおいてアジャイルである必要は無さそう 例えば、受託開発のような場合はつくればお金がもらえるということになっているので、アジャイルになろうというモチベーションは低そう デリバリーにおいて十分な能力を有している=やるべき正しいつく

「LeanとDevOpsの科学」を実際にチームに適用した際の工夫 - talk at DevOpsDays Tokyo 2022 こんにちは、株式会社ビズリーチでプロセス改善活動をしている賀茂といいます。 少し前になりますが、2022年4月21日にDevOpsDays Tokyo 2022にて発表をしたので、発表内容の補足と発表後に会場の方からもらった質問について答えたいと思います。 発表内容について 今回は『ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 』と題して「LeanとDevOpsの科学」という書籍の実践事例を発表してきました。 「LeanとDevOpsの科学」について 前提として今回の取り組みは「LeanとDevOpsの科学」という本を参考にしています。 「LeanとDevOpsの科学」では開発組織のパフォーマンスを測る指標（Four keys

ヘキサゴナルアーキテクチャを利用したLambda 関数のドメインモデルの実装 Live AWS Summit 2022 Developer Zone (dev-09) セッション資料です。

皆さんこんにちは採用担当のnabeです。 突然ですが、皆さんのITエンジニアのイメージはどんな感じでしょうか？ 食いっぱぐれがないとかコロナ不況下でも仕事があったりとか、 長く働けるとか、簡単に高収入もらえそうとか、 残業多そうとか、ブラック企業多そうとか、 色んなイメージが先行しているとは思いますが、 これって本当なの？？？って私も思ってしまいます笑 今日はそんなIT業界のエンジニアにこれからなりたい方にお届けしたいお話しです。 まず最初に、この業界を志す方は、 コンピュータ専門学校や大学でコンピュータ系の学部を出ていたり、 個人的にプログラミングが好きで個人活動をされていたりして新卒時に就職活動をしてこの業界に来られる方だと思います。 その他では、IT業界に魅力を感じて、 ハローワークの職業訓練やプログラミングスクールに通ったり、 Webなどで人気のRubyやPHPなどでWebサービス

この記事に書いてあること 指摘の仕方に気を付ける事の利点 オススメの指摘方法 ※何かを強要したり、コミュニケーションの仕方を責めるものでは無いです。Tip集みたいなものだと思って気楽に読んで下さい。 導入 社内外で関わる方（特にエンジニアの方）に対して、「（指摘の仕方で損をしているな〜）」と思う事が多くあります。 Twitterで呟いてみたところ、 「そうは言っても中々苦手…。」 「気を付けてるつもりだけど、キツい言い方になってないか不安」 といった反応をいただきました。 そこで下記について、私なりの考えをまとめました。 指摘の仕方に気を付ける事の利点 オススメの指摘方法 本論 指摘の仕方に気を付ける事の利点 指摘の仕方について、ちょっと気を使うと良い事がたくさんあります。 具体的には下記の良いことがあります。 感謝される 指摘内容を前向きに検討してもらえる 誤解されずに済む それぞれ解説

テスト自動化の成果をどう評価し、どう次につなげるか/Test Automation Next Step

Twitterで考えながら書いていたこと（以下のスレッド）を整理したエントリです。 https://twitter.com/murashit/status/1404730372273762306 あらかじめことわっておくと： アトリエシリーズはエリー以降やったことがない、つまりシリーズ他作品でどうなっているかは、ごめんなさい、知りません…… 当のアトリエシリーズを含め（以下で説明しているような特殊性をおびた）類例はほかにもあると考えられますが、おれ、そんなにゲームやってないので…… また、この話をもし本作全体の評価につなげるのであれば、最後のほうで言ってる「そのほかの要素とあいまって」の内実やガスト制作チームの意図あたりを詰めなければならないのですが、それはさすがに自分には荷が勝ちすぎる（し、その情熱もねえ！）。ということで、ほとんどこの2つ（以上）の「時間」についての整理のみです。 あと

ようやくPS5を買った。GT7をやるためである。 さて、GT7はレースゲームであり、またお手本として「現実」があるタイプのゲームである。現実というのはつまるところ現実の自動車及びそのレースのことであり、基本的にはこれらをどのようにリアルに再現するのかという点に心血が注がれている。もちろんのこのリアルさというのは世代が進むごとに強化されており、リアルなグラフィックと挙動というのが(GT7に限らず)リアル志向レースゲームの売りとなっている。 しかし、そんなリアルなゲームであっても意図的にフィクションを残している部分がある。それが時間である。 どういうことかというと、GT7の世界には少なくとも二つ以上の時間が同時に流れている。一つはラップタイムを司る時間──これは現実世界の時の刻みと同じである──そしてもう一つは「ゲーム内で流れているであろう時間」である。これは現実世界の時の刻みとは非同期なもの

ここ二ヶ月ほどアメリカで無職をやっている。結果から言うと無事転職先が決まったため既に先が見えた無職生活であるが、Temporary Worker Visa で働く人間が突如職を失うととどうなるかという貴重な経験だったため備忘録を残す。 無職以前San Francisco の Fintech Startup で Sr. Software Engineer として働いていた。前々職でもシリコンバレーで日系企業の駐在員として働いており、帰任と同時にオファーを貰って転職した。会社は H-1B ビザの申請をサポートしてくれて抽選にも通ったが、コロナ禍により大使館面接が停止し、結局一年以上日本からリモートで働いた後、2020 年末にやっと渡米することが出来た。 会社の特徴としては全面的に Clojure を使って開発をしていた。元々 Clojure Developer であった自分が採用された理由であ

ピザ2枚ルールというのがあって, チーム編成するにはピザ2枚が配れる人数(8人前後らしい)が良い, と言われている. このあいだ雑談した時に, これはオフィスにみんないることが前提なんじゃないか? って話をした. 8人くらいのチームだと, フルリモート環境だと人数が多すぎて, 会話とかものすごくやりにくい気がする. リモートで話すの, やっぱり難しいと思っていて, そうなってくるとフルリモートに適切なチームの規模, というのがありそう. 結果として, 4人くらいがいいんじゃないか, という話が出てきて, ｢なら, "雪見だいふく2袋ルール"ですかね?｣みたいな話をしていた(雪見だいふくは通常1袋に2つ入っているので, 2袋で4個なので4人で分けられる). 人とやっていくの難しいし, リモートでやっていくのも難しい, となると, リモートででっかいチームうまく回していくの難しさがある気がする

Kuro Gameは5月26日、『Wuthering Waves（鸣潮）』を発表した。本日5月27日には、ゲームプレイ映像も公開している。開発はまだ初期段階であると明かされているが、ド派手な映像がSNSで反響を呼んでいるようだ。 『Wuthering Waves』は、オープンワールドアクションRPGだ。高い自由度の、ストーリー・リッチなオープンワールドRPGになるという。ティザートレイラーでは、砂煙が舞い天変地異に見舞われた大地を、刀をもった美少女が疾走する姿が確認できる。荒廃した大地を冒険するのだろう。 ゲームプレイ映像では、前出の刀美少女らが広大な世界を冒険している。壁を蹴ってビルを登ったり、宙を舞って敵を攻撃したり、投擲武器を使いつつコンボを披露したり。敵の攻撃を避けることでスローモーションになるといった演出も用意されているようだ。あくまでデモンストレーションが目的の映像で、最終的な

いつもホッテントリを賑わせている増田だが、増田が始まってからこれまでの１５年間について、年代別にブクマ数ベスト５を調査して、振り返っていきたい。 2006年1位：プログラミング用のフォントを探してたら一日が終わってた(366users) この時代は「技術のはてな」みたいに言われていたので、こういう記事に需要があって、よくホッテントリ入りしていた。 なんで増田に書いたのかよくわからんが。 2位：anond:20061214085342(155users) 有名なオーケン事件の2chコピペ。 2chコピペだとわかるように書いてある。 3位：手っ取り早くGIGAZINEになる方法(140users) gigazineはこの時代のホッテントリ常連だった。 deliciousとかdiggとか今はもうなくなってるよな。 4位：『はてな』がイノベーターに成り得ない５つの理由(132users) 頭のおか

あゝボクたちは楽器ができないリア充たちが楽器を振り回し歌い上げるその姿を観続けて幾星霜。 奴らがスポットライトを浴びキラキラ輝けば輝くほどオーディエンスの瞳孔は開きボクたちは暗闇へ包まれて誰の目にも映らなくなる。 あゝボクたちは楽器ができない。もしもピアノが弾けたならボクたちも少しは輝けるのだろうか。 頭の中のメロディを出力することは諦めろボクたちが楽器をやろう音楽を作ろうとするときに、陥りがちなのは頭の中のメロディや音を再現しようとすること。 それは諦めるべきことでボクたちにそんな才能がないことはボクたち自身が一番知っていることじゃないか。 こんなポエムのようなエントリに興味を持っている時点でキミはボクと同じ側であり才能のないクリエイターだ。 なぜ頭の中のメロディを再現できないのか、なぜ再現する方法を教えてくれないのか、なぜ再現してはいけないのか。 それはキミに才能がないからで、そしてボ