定期的に DDD やクリーンアーキテクチャなどを題材にした記事が盛り上がっているのを見ていると、いま長年の疑問を書けば誰か答えてくれるのではと思って書いてみる。 何に困っているかというと、 いわゆるレポジトリ層が持つ create/update 関数の引数は Entity で待ち受けるべきか、プレーンなオブジェクトで待ち受けるべきか分からない ユーザーから POST Body されたデータにはビジネスルールを適用させるべきか（= 一度 Entity を作るべきか）分からない だ。 Entity を作らない場合、いわゆるトランザクションスクリプトと呼ばれているものに近づく。 そしてトランザクションスクリプトには結構否定的な意見も見られる。 しかし、自分は Entity を作ることが必ず正解とは思えず、レイヤードな設計とトランザクションスクリプトを組み合わせる設計の余地もあると思っていて、トラ

新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと！！！」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker

GW なんも予定がなくてブログ書くかソシャゲやるか昼から酒飲むしかやることがないです。だから予定があったら使っていたであろうお金でソシャゲに課金したらめちゃくちゃ強くなりました。やったー。友達にはドン引きされましたが、GW に予定がある人よりかは節約できていると思います。そんなソシャゲもやることなくなって暇なので酒飲みながらブログを書きます。今日は WebRTC です。 免責 筆者は RFC を読んでいません。これは「そもそも WebRTC それ自体 の RFC なんてものは存在しないもんね〜」という意味でなく、ICE や SDP の RFC すら読んでいないという意味です。そのため WebRTC そのものの解説として読むと良くない表現が含まれるかもしれません。ただし自分が WebRTC でカメラ映像を送る実装を動作させ、そのコードの解説という点では間違ったことは書いていないはずです。動作

お願い 「C10K 問題とは何か」がわかる方は是非 Issue や Twitter などで教えてください。 追記: 自分の立場 1req ごとに 1 native thread を割り当てていたら、クライアントの数が増えれば増えるほど負荷が高まるのは当然だ。ただハードウェアの性能的に余裕があっても性能が劣化することがあり、それを C10K 問題と呼ぶ。C10K 問題は fd, pid の枯渇、スレッドを固定長サイズで確保することによるメモリの無駄遣い、コンテキストスイッチコストを含む。これを解決する方法が 1req ごとに 1 native thread を割り当てない技術で、シングルスレッド+イベントループ+IO 多重化といったテクニックや M:N モデルにつながる。 追記: @naoya_ito さんに解説してもらった当時の歴史的背景 https://twitter.com/naoya

一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat

Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ