20240831 あとで読む消化

久しぶりに本書を読み直した。最低限Rubyでコードを書くときに意識することがまとめられてて良い。

でも継承はやっぱ使わんほうがええなという気持ちはある。変更容易性を担保する->単一責任原則・依存性の管理・インターフェースの設計。この辺り意識するだけで80%ぐらいはマシになるはず。

Postgresと大体同じエンジン。標準SQL。

独自拡張のSQL構文が面白そう。

原典はこれ

エンジニアリングチームで気をつけるべき20のパターン

エンジニアリングチームによくある良いパターン/悪いパターンのまとめ

GMV

Gross Merchandise Valueの略称で、日本語に訳すと「流通総額」のこと

モール型ECサイトやアプリなどのプラットフォームにおいて顧客が購入した商品の総額のこと

railsのmodel/controllerのconcernsの運用の決定版を自分の中で持っておきたくて読んだ

concernsの配置

モデル共通のconcerns: app/models/concerns/ディレクトリに置く

特定モデルのconcerns: モデル名と同じフォルダに置く（app/models/<モデル名>/）

concernsに全てまとめないの良いな

私は「concerns vs 他の何か」のような二項対立的な考え方は誤りだと思います。concernsの概念を利用したところで、システム設計が楽になるわけでも不要になるわけでもありません。

責務の分割にはconcernsではなくオブジェクトを作るべき

基本的なオブジェクト指向の設計の上に味付けする機能がconcerns

TechRachoにこのシリーズの日本語訳が全部あるので後で全部目を通すか

Goで肥大化したRepository層とServiceに書かれた煩雑なロジックをドメイン層の導入とRepositoryの整理で改善した話

リファクタリングは明確な目的を持って範囲を絞るのが重要。できるだけ既存事業に影響でないようにしたい。

最初から完璧に設計できれば...とか普段から少しずつ負債を解消できれば...みたいな話はスタートアップだと人も少ないし速さも優先したいし難しい

HEYが開発してるアプリの買い切り版。無料でzipをDLできる。

Hotwireのお手本

言わずと知れたマストドン

Rails API+reactのお手本

dev.toのOSS版

Rails + preactで一部SSRのMPA。island architecture。

メモ帳を探してるところで出会った記事

Vimでローカルに適用に書いてDropboxに自動同期させてた。

今はせっかく有料版Cursor契約してるしCursor使いてぇなという気持ちがある。