タグ

ブックマーク / capsctrl.que.jp (5)

  • capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..

    1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j

  • Martin Fowler's Bliki in Japanese - トランザクションレス

    http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新:Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって(私もそうだが)トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ

    hamasta
    hamasta 2007/03/24
    >eBayでは滅多にデータベーストランザクションを使用しない
  • Martin Fowler's Bliki in Japanese - 生産性は計測不能

    http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし

    hamasta
    hamasta 2007/02/02
    >チームの生産性が分かりづらいのであれば、個人のチームへの貢献度はさらに分かりづらいものでしょう。
  • Martin Fowler's Bliki in Japanese - FrontPage

    ここは、Martin Fowler's Bliki の翻訳Wikiです。 Martin Fowler氏人の許可を得て公開しています。 Wikiですので、どなたでも参加可能です。 ご自由にページの追加、修正、変更を行ってください。 まずは およみください をどうぞ。 ご意見は ご意見箱 までどうぞ。 ページ一覧からページをご覧いただけます。 まだ翻訳していないページは、InHandOrNotまたはKeywordListUntranslatedで確認できます。是非、「新規作成」してください ;-)。

  • ドメインロジックとSQL

    以下の文章は、Martin Fowler による Domain Logic and SQL の日語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの(rich SQL queries)を用いるので悪しからず。 エンタープライズアプリケーション(訳注:以下、EA)構築に関する(私の近著『P of EAA』など)を読むと、ロジッ

    hamasta
    hamasta 2006/01/15
    SQL-philosophy あとで読む
  • 1