タグ

railsとarchitectureに関するmanabouのブックマーク (3)

  • ~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計 - dely Tech Blog

    こんにちは、delyコマース事業部エンジニアの小川です。 先月11月に入社し、エキサイティングな毎日を過ごしています。 この記事はdely Advent Calendar 2019 - Qiitaの24日目の記事です。 昨日はSREの松嶋さんが「AWS RunCommandを使ってEC2上に監視ダッシュボードをサクッと作る(Ansible+Terraform+Grafana編)」という記事を書いてくれましたので是非そちらも読んでみてください! tech.dely.jp コマース事業部では、現在「事業開発」と「ソフトウェア開発」がほぼ同時に進行しており、プロジェクトにおける確定要素と不確定要素が複雑に絡み合っています。 スピード重視でゴリゴリ実装していくのも興奮しますが、変化に耐えづらい実装をしてしまうと、その後の開発スピードに影響していまい、事業のスピードが落ちるなんて事にもなりかねません

    ~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計 - dely Tech Blog
  • DHHはどのようにRailsのコントローラを書くのか | POSTD

    私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

    DHHはどのようにRailsのコントローラを書くのか | POSTD
  • Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita

    この記事はCrowdWorks Advent Calendar 2016 の24日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 昨日の記事は @suzan2go による「ラーメン屋で考えるRailsのデータモデリング」でした。 はじめに CrowdWorksは、2011年の創業以来、約5年間の開発を続けてきました。サービスの立ち上げ期においては、サービスの継続性・変更容易性を高めることよりも、サービスを成長させ、存続に繋がるフェースまで素早く立ち上げることが最重要な観点です。 一方で、サービス提供も5年が経過し、多くの方にご利用頂く「社会インフラ」に一歩ずつ近づいてきています。そういった環境の変化もあり、「日々改善し続ける」「日々変更し続ける」ことに重要視する観点が移り変わってきました。そのような価値観の変遷に取り組む過程で考えている「大規模で複雑な業務要件を担う

    Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita
  • 1