中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
《REST思想》と《リソース指向》と《Webページ》に関する（主にRailsの）話 - Qiita
これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。 実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません（もちろんAddressabilityの面で重要であることは言うまでもありません）。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。 本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは
suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
国内最大規模のRuby on Railsサイト「クックパッド」の裏側見せます。 - そうだ車輪と名付けよう2nd
日時 2009年1月31日（土） 14:10〜14:55会場アクロス福岡 608会議室スピーカー 橋本 健太 氏概要イベント&セミナー情報｜PASONA TECHレシピサイト、 レシピ検索No.1／料理レシピ載せるなら クックパッド を運営するクックパッド株式会社のCTO 橋本氏がスピーカー。実は俺クックパッド自体は使ったことない。まとめユーザがマニュアルやFAQを必要とするサイトは、どこかに問題がある。なにかを開発する際には、開発期間と同じだけの設計期間や品質チェック期間を設けるクックパッドについて1998年オープン(当初は有料サイト)547万人/月2.8億pv/月登録レシピ数は、47万品目アクセスのピークは16時から18時Ruby on Railsで作られたサイトとしては、世界7位の規模、国内最大規模。レシピサイトとしても、世界最大規模。アクセス数を捌くためにDBの構造やサーバ周りにつ
RESTfulな設計とCRUDはちょっと相性悪いという話 - yojikのlog
http://www.infoq.com/jp/news/2009/08/CRUDREST 上記URLを読んで自分なりに例題を考えてみる。(todo:あとで状態遷移図を追加) RestBucks cafe 完全にオンライン化されていてWebAPIで注文できるというすごいカフェを想定します。(この手の例にStarbucksを使うのはGregor Hopeさん以来の伝統らしいです) 客側から見たユースケースはこんな感じ 客はレジのサービスを呼び出して、注文を入力して支払い 自席で注文状況をチェック、出来上がっていたら取りに行く。 注文というエンティティと、[注文編集] [支払い] [受け取り] という(アプリケーション)状態によって上手く表現できそうです。 (RESTfulだけど)CRUDな設計 CURDな設計では、リソースをURLにマッピングします。それに対してCRUDするというイメージです
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
システム設計 設計の考え方
要件定義、基本設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基本的には必要とされるアクターを考えることが重要だと思われる。 外部設計（システム設計） ＝システム方式設計+ソフトウェア設計 内部設計 ＝コンポーネント設計 詳細設計 ＝プログラム設計 （IPA） １．システム方式の決定：アーキテクチャーとして、H/
成果物から設計書へ - 変わりつつあるソフトウェア開発の価値観 - 2
成果物から設計書へ はじめに コンピュータがこの世に登場した頃、プログラミングという作業は設計工程が終わってから行われる作業と考えられていました。 つまり、プログラミングという作業は、設計図に従ってものを作る「モノ作りの作業工程」であると考えられていたわけです。 これを当時一般的であった建築のアナロジーに当てはめると、プログラミング（実装工程）とは「設計図を基にして実際に建物を建築する」工程になり、プログラマは「大工」ということになります。 実際に、現在でもこの考え方に従ってソフトウェア開発を行っている組織が数多くあります。 しかし、1992年にJack Reevesという人は、「ソフトウェア設計とは何か」という記事（C++ Journal）の中で、「ソースコードは設計を表現したドキュメント、つまり設計図であり、プログラミングという作業は設計工程の一部なのだ」ということを主張
上流工程AtoZ - IT Pro
情報システムの開発では，いくら先進的なプログラミング手法や実装技術を用いたとしても，ユーザーにとって望ましいシステムが，予定通りの期間・コストで完成するとは限りません。ユーザーに対する的確な「提案」，ユーザーの要望を仕様化する「要件定義」，作業工数や開発期間などを予測するための「見積もり」，システムの最適な構造をデザインする「設計」といった「上流工程」の作業を的確に行う必要があります。そのための基本知識やノウハウを，是非この特集サイトで身につけてください。 見積もりをプロジェクトにつなげる 見積もりは通常，プレ・プロジェクトと呼ぶ段階で，提案活動に付随して進めます。では，提案活動に付随して行う見積もりが，なぜ切り出されてこれだけ注目を集めているのでしょうか？ 私は，スコープや工数，コスト，納期など，マネジメントの要素が見積もりに集約されているからだと考えています。 (2006/11/3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第1回：DOAを採用した現場の実態とは (2/3)