Atomic Design における Atom, Molecule, Organism の見極め方 - assertInstanceOf('Engineer', $a_suenami)
最近フロントエンド書いてて、コンポーネントの設計とかデザイナーとのコミュニケーションには Atomic Design を採用しているのだけど、まあよくある話として「この要素が atoms / molecules / organisms のどれにあたるかわからん！」となる（なった、特に molecules）ので、チーム内に雑にテキストで書いて共有した。で、せっかくならそれを公開して優秀なデザイナーおよびフロントエンドエンジニア諸氏に意見を募りたいと思ったのでブログ書いてみることにする。 ちなみに、現状は実装対象として Web アプリケーションを想定しているけど、ネイティブアプリも視野に入ってるので「HTML ではそうかもしれないけどネイティブアプリだと云々」みたいな意見も歓迎する。 チームに共有したテキストがこちら。 Atom, Molecule, Organismの見極め方 Atomic
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
