iPhoneが登場したとき、某研究所の技術者たちは「その要素技術はすべて日本が持っている」と語ったらしい…。まぁそらそうでしょ。小さいPCなんだから。破壊的イノベーションは高度な技術があれば実現できる、と思い込んでるところあるよね。
加藤潤一(かとじゅん)
加藤潤一(かとじゅん)
58.9K posts
加藤潤一(かとじゅん)
@j5ik2o
INFP - AH/ IDEO;PLUS社代表/ZOZO, Leverages, Precena技術顧問/
個人エンジニア支援→x.gd/t7ofq
お仕事の依頼は→ bit.ly/3kIYMJU
テスラ割引購入→ts.la/junichi233326
加藤潤一(かとじゅん)’s posts
「C言語なら所有権なんて考えなくてよかったのに、Rustだと考えることが増えた」みたいな話を耳にしたとき「えっこの人 自分でメモリやリソースの管理できないままCでコード書いてたのか…」とドン引きした覚えがある
エンジニアの採用は企業からみたらレッドオーシャンなんであの手この手なんですが、本当の課題は入社した後のエンゲージメントなんだよね…。そしてエンゲージメントはチームに宿るんだという論文を学んでいる。だから簡単にチームを解体するのはもったいないね。
最近、Userというモデル名を例に説明すること自体やめた方がよいと思ってるんです。ユーザーはシステム外。アカウントや住所や氏名や職位や部署。一見Userに含まれそうだけど同じモジュールに閉じ込める必要あるかな。UserAccount, UserProfile, Employeeとか目的ごとに分けないと神モデル行き。
実装コードがクソコードとかウンコードとかいうのはいいのですが、散々リファクタリングして時間掛けて苦しんで、最後に「実装というより仕様が複雑でした」というオチになるのが一番最悪なのでリファクタリングする前にその仕様で大丈夫か確認しましょう…。
2024年12月31日付でkubell社（旧Chatwork社）を退職しました。2014年から在籍して約10年、直近では最も長く続いた経験でした。
今年からは自分の会社で技術顧問や開発支援（実際にコードも書きますよ！）を中心に活動していきます。
DDDの入門向けの記事を書きました。よいきっかけになればうれしいです。
ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう - エンジニアHub
employment.en-japan.com/engineerhub/en
クリーン・アーキテクチャという形式的なアーキテクチャパターンがあるわけではなくクリーンなアーキテクチャを実現する原則や観点をまとめたものが「クリーン・アーキテクチャ」。ボブおじさんが例示したHowを無根拠になぞることがクリーン・アーキテクチャではない、という理解でいいと思う
これな。大量退職を経験した過去の経験からいうと。中間管理職の人たちが情報の省略・歪曲・一般化を誤って行うことが原因かなと思う。良かれと思うとか関係なく…。なので必要な情報は公開されていて各自の頭で考えて行動できるかに尽きる。当たり前のように聞こえるけどなかなかむずい
Quote
kawasima@99卒
@kawasima
話に聞く限り、
事業を拡大する→エンジニアが一気に増える→マネージャも増やす→特定のマネージャとエンジニアが衝突する→エンジニア大量流出
のパターン多すぎなので、早いことマネージャに人類以外をアサインするソリューションが求められる。
Rustで作ったコンテナが4秒でスケールアウトして、消費メモリもKB単位だとか。これ実質Lambdaでは？えっほんとに動いてんの？というツッコミが社内チャットに流れてる。ワロタ
クソコードを晒して知見を得る姿勢がある人たち尊敬します。純粋にね。いろいろ背景あったわけで、えーってこともいろいろある。でもクソコード晒さないで、マウンティングする人たちは尊敬できないね。やっぱり行動を起こすってすごいコトですよ
技術負債が溜まったクソコード？はまさに考古学の研究者のような姿勢が必要でまず背景も知らずに批評するのではなくなぜそうなったかコードやドキュメントを探索。まぁだいたいそういうのは不明なので関係者を取材したりする。当然、コード書いた本人がもう退職している場合もある。またコードを見る…
#Zenn で何か書いてみようということで、Scalaの薄い入門本を書いてみた。
良かったらどうぞ。
「楽しいScala 気軽にはじめてみよう」
Content warning:
The following may contain sensitive material
今日はCTO候補の人と「HTTPやDBに依存しない形でモデルを考えるのが苦手なメンバーが多い」という話をしたんだけど、O/Rマッパーやフルスタックフレームワークの影響を受けすぎなんでしょうかね。結局のところ設計って、有るべき姿を設定してWhyやWhatを問い続ける行為だよね。
「悪いコード」というのはコードだけみると悪いかもしれないが、他の目的を達成しているのではないかという見方が必要。一介のエンジニアの範囲を超えるかもしれないが実際の仕事ではそういうメタ思考をしないと目の前のコードを批判できないこともある。そういう観点をみんなに持ってほしいと思ってる
たぶん、Userモデルなんてないよって言い出したのは、僕ですが、わかりやすくまとまっている！がーさす！みんな読むべき資料ですね！そして祝出版！ / 2件のコメント b.hatena.ne.jp/entry?url=http “クソコード動画「Userクラス」で考える技術的負債解消の観点 - Speaker Deck” htn.to/3DcxFj3dfW
Content warning:
The following may contain sensitive material
この論文(2021年)が面白い。マイクロサービスの分割単位についての論文。
No Free Lunch: Microservice Practices Reconsidered in Industry
researchgate.net/publication/35
51のプロジェクト中4プロジェクトがDDDの指針に沿ったが、大半のプロジェクトはエキスパートの経験に基づいて分割した、と。
Content warning:
The following may contain sensitive material
Kotlinのサーバサイドは微妙というのはだいぶ前につぶやいたことあるけど。エコシステムが完全にJavaだし、Java開発者がターゲット。で、Javaの進化がかなり進んでるので長期的にみたら別にJavaでいいんじゃねになりやすい。
仮説として、採用はどこもよその畑で育ったエンジニアを引っこ抜いてる感じで、基本的に育てないという構造的な問題があるように思う。以前は若手なら育てるという傾向があったが、業界の高齢化が進み若手も減少してきた。その結果、中堅エンジニアを今さら育てる必要があるのか、という疑問も生じてい
勉強しないやつは死ねばいいと昔はよく言ってましたが、ほとんど言わなくなりました。自分の課題と他人の課題を分離できていないから筋が悪い。もちろん手助けはしますが結局やるやらは相手の問題なので。職場では勉強云々より期待値コントロールとコスト負担がクリアできればよいかなと思ってる
勉強会とかで「質問ある人〜」って聞いて手を上げないのはその人が悪いのではなく、その人たちがアウトプットしてないから疑問なんか生じないって話。疑問や質問を作って学びたいなら勉強した話を聞くのではなく、その場でアウトプットするようなワークショップが適切
Replying to
持続的なイノベーションで使われる技術は高度なものが多いが破壊的ではない。その背後には顧客の要望がある。一方で破壊的イノベーションは技術的には簡単なものが多いし、発明が必須というわけではない。というか、技術自体の高度さに捕らわれないほうがいい。まぁ誤解している人多い感じはする。
スライド資料です！ご査収くださいm(_ _)m / AWS Dev Day 2018 ドメインモデリングの始め方
PHPやJavaだと開発者人口が多いので採用が楽だはほんとかな。例えば堅牢なソフトウェアを設計できる能力が求められるならプログラミング能力以外に設計力も必要。そういう人を探すとなると どうしても少なくなる印象。コーダがいればいいという仕事なら別だけど、スタートアップではオススメできない…
人と話してると「すぐそんなにアイデアがすらすらとでますね？」って言われる。そう言う人は大分勘違いしている。答えは簡単で「日頃から考えているアイデアをその場の状況に合わせて話しているだけ」です。思いつきで話すのもいいけど、準備して望んでる人の差は大きいですよ。やっぱり。
以下の設計に従った実装がみたいという要望がたまにくるので、Rustで雑に作る予定。乞うご期待。
Content warning:
The following may contain sensitive material
設計本を読むとほぼ二項対立になっている。A vs BはAがよいとか。理由を読んで自分の頭で考えよう。Bは本当にダメなのか。前提が変わってもAが正しい選択と言えるのか考えよう。前提が変わっても設計として変わらないものはなんだろうか。このようなAかBかの線引きの難しさを学ぶのが設計本の醍醐味。
昨日の「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス」で話したスライド資料です<(_ _)>
「過去の失敗例から再考するモデル駆動設計 」
speakerdeck.com/j5ik2o/guo-qu- #mixleap #genbadeddd
Replying to
このことは、フォードの「もし私が何が欲しいかと聞いていたとしたら、人々は『もっと速い馬』と答えただろう」の言葉にも繋がる。破壊的なイノベーションのときは、顧客の要望をヒアリングしてなんとかするじゃなく、顧客の期待の先に行かないといけないわけだ。全然考え方が違うし凄く重い意味がある
映画料金を算出するドメインモデルを考えている。できるかぎり、実行時表明を使わずに型レベルの表明でドメインモデルを作りたい。頭の体操。さぁみんなもやってみよう。
cinemacity.co.jp/ticket/
テストがないコードをみると設計以外に動作も怪しい。設計の善し悪しやリファクタリング以前に、それ本当に完成してるの？まさか手で動作確認してるの？？という気持ちになる。時間がないからテスト書いてないって話も多いんだけど、逆だよね。時間がないなら余計にテストが必要なんだけど…。
Railsでドメイン駆動設計に基づく実装をするにはどうしたらよい？って相談受けることあるのですが、無理があるので辞めましょうって話してる。hanami を使うならまだしも…
hanamirb.org
日本は賃金が安いだから海外に出稼ぎしようとなるのは分かるが、そもそも理想は日本にいながらリモートでドル払いの仕事をすること。つまりドルで得て使うときは円で使うほうがコスパがよいのではと思う。もちろん渡航して語学力を上げるならこの限りではないが稼ぐだけならこのパターンがいいなと。
スライドをアップデートしました。最近せっかく認定スクラムマスターになったので、アジャイルとの関連性を盛り込みました (笑)
#ooc_2020
クエリのN+1問題回避のためにもCQRSは採用すべきで、集約をまたがるクエリ要件はドメインから外したほうがよい。リポジトリでなんでもかんでも頑張り過ぎないほうがよいんだよなー。これは結構強い動機付けにつながる気がしてます。
ここ最近ずっと言ってるんですが、DDDを理解できるようになりたければ、「エンジニアの知的生産術」の「第1章 新しいことを学ぶには」だけでも読んで欲しいんですよね。モデリングのエッセンスが凝縮されてます。
CRUDしか要件がなくて…という話はよくある。よく聞くとシステムからCSVエクスポート→エクセルのセル内で何か計算して仕事に役立ててる。"えっそれがビジネスロジックの一つでは？なんでシステムの外側でやってるんでしょうか？"こういう指摘がそもそもできないと貧血症を避けられないというのはある
ときどきEvansの"声に出してモデリングする"を笑う人いるんですが、そういう人ほど人間の言語処理能力を過小評価してて、クラス図を書いたらモデリングした気になってるパターン多くて…。モデリングに必要なのは国語力だと思ってる。
アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。
副業でZOZOさんにアドバイスさせてもらっているのですが、Akka以外でのCQRS/ESの方法を一緒に設計しました。かなり参考になると思います。
techblog.zozo.com/entry/implemen
zenn.dev/j5ik2o/article
Content warning:
The following may contain sensitive material
レイヤ化アーキテクチャに対応するパッケージを切る。データはエンティティとロジックはサービス、永続化はレポジトリを実装。これがDDDだと思っている人多い。トランザクションスクリプトですよ。
Replying to
クリステンセン曰く「顧客の意見に耳を傾けることがまちがっている場合、性能が低く、収益率の低い製品の開発に投資することが正しい場合、主流市場ではなく小規模な市場を積極的に開拓することが正しい場合がある」顧客の声を聞いていては破壊的なイノベーションは生まれない可能性があるってこと。
DBのテストデータを手でINSERTするのはもうやってない。ドメインモデル＋プロパティベースドテスティングのジェネレータモナドとリポジトリを使い、DBに事前データを作らせている。そういうも記事したほうがいいかもな。
DDD について語るとき、かとじゅんさんや増田さんから何を言われるか怖くて…という話聞いたけど、あなたが思い通りにやりましょうと言ってきた。議論を広げるという意味で価値値のある行動だし、ぼくらが唯一正しい選択をしているわけではないので…。議論は積み上げるものですよね。
情報収集して自分の中でロジックを作るところで終わらず、手を動かてみるなどの実践・検証がないから自分のものにならないだけやで。他人の知識はそうらしいという情報であって、使える自分の知識するには筋肉を使わないと無理。
Quote
hpeo
@hpeo_it
自己啓発
サーバーサイドKotlin触ってみて思ったのは別にJavaでいんじゃね？ってこと。いや確かにモダンな書き方できるし自分はKotlinもよいと思うし今ならKotlinで書くけど、Javaもものすごい勢いで改善するだろうから差異は埋まっていく可能性があるんだわ……長い目で見るとJavaでよくね？と言う人多そう
某ゆーちゅーばーさん、心理的安全性を誤用されていますね。これ読んだほうがよいです。全く逆の意味で誤用されていると思われる
Latest topics > 誤用の心理的安全性 - outsider reflex piro.sakura.ne.jp/latest/blosxom
ドメイン層にてdomain/{entities, vo, enums}のようなパッケージングされているをみると「ドメインをわかっていない人がコード書いている?!」と思ってしまう。知識がフラグメントしまくってる。domain/{account, order}とかであればわかるけどね。
「テストを書く時間ないんですよー」という人が、コーディングエージェントを手にしてもテストを書かせないことがあり…。時間がないのではなく、考えてないだけでは説
非同期・ノンブロッキング、背圧制御とか考え出すと関数型のモデルが必要。1リクエスト1スレッドとかデカすぎるし。細粒度タスクでスケジューリングできないとつらい。JavaでもServletじゃなくてSpring WebFluxの方向に向かうのは自然の流れ。
みんなドメインサービスに永続化責務を持たせてもいいと勘違いしているなー。ドメインサービスは別名”ドメイン関数オブジェクト”なんだよ。人工物なんだけどE,VOと同じドメインオブジェクトなんだ。これらは永続化責務は持たないのだから内部でRepositoryを使わないでほしい。というのが僕の考えです。
Scalaはとてもよい言語だと思う。がランタイムがLambda用途だけでなく、Docker/Kubernetesなどのクラウドネイティブ時代に合わないという話なんですよね…。システムが分散化されると、どこかでインスタンス入れ替えが発生する頻度が高い。そのたびに起動に時間がかかるとか、JITの暖機運転が必要とか