タグ

ブックマーク / forza.cocolog-nifty.com (5)

  • 同期・非同期処理に関するアーキテクチャ - プログラマの思索

    同期・非同期処理に関するアーキテクチャで良い記事があったのでメモ。 【元ネタ】 ITシステムで見られるシーケンス データベースコンサルタントのノウハウちょい見せ ダメな設計は、シーケンスが階段状ではなく、一つのオブジェクトに全ての処理を任せる「責任が肥大化したオブジェクト」がある。 特に初心者が、設計を考えずにいきなりプログラムを書いたり、システムを作ってしまう場合によく見られる。 この設計では、スパゲティコードになりやすく、一つのプログラムが千行を超えて保守しにくかったり、スケールアップや性能要件で壁にぶつかる時が多いだろう。 Webシステムは基は、上記記事の「三角形」シーケンスに相当する。 メッセージを階段の図のように渡して、処理の結果を受け取るイメージ。 オブジェクト指向の権限移譲では、この設計手法がよく使われる。 MVC2モデルと呼ばれるように、Webシステムはオブジェクト指向と

    同期・非同期処理に関するアーキテクチャ - プログラマの思索
  • 業務ロジックをデータモデリングはどこまで表現できるか? - プログラマの思索

    「業務ロジックをデータモデリングはどこまで表現できるか?」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model

    業務ロジックをデータモデリングはどこまで表現できるか? - プログラマの思索
    Jxck
    Jxck 2012/11/05
    書籍の正規化の説明は、多くが情報処理試験の問題に引っ張られすぎと感じる。設計の観点でちゃんと学ぶのって、案外難しいなと思う。
  • 分散バージョン管理はバージョンではなくリビジョンを管理する - プログラマの思索

    InfoQの分散バージョン管理の記事を読んだ後に、もう一度、JoelがMercurialについて書かれた記事を再読して、ようやく分散バージョン管理が従来のバージョン管理ツールと何が違うのか分かったのでメモ。 ラフなメモ書き。 殴り書きの部分は後で直す。 【元ネタ】 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project JoelもMercurialを使っている: プログラマの思索 InfoQ: エンタープライズ分野での分散バージョン管理システム 分散バージョン管理の可能性: プログラマの思索 (前略) 分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。 重要なのは、このシステムが「バージョン」ではなく「変更」(注釈:リビジョン)で物事を捉えているということだ。 (中略) Subvers

    分散バージョン管理はバージョンではなくリビジョンを管理する - プログラマの思索
    Jxck
    Jxck 2012/06/21
  • グーグルが構築した大規模システムの現実、そしてデザインパターン - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    グーグルが構築した大規模システムの現実、そしてデザインパターン - プログラマの思索
  • TracやMantisによるチケット駆動開発の運用方法 - プログラマの思索

    最近、RedmineではなくてTracやMantisを使う機会が多い。 チケット駆動開発をTracやMantisで運用する方法について考えたことをメモ。 【チケット駆動開発を運用する時の注意点】 Redmineでなくても、TracやMantisでもチケットをXPのタスクカードのように扱うことはできる。 BTSのチケット管理をプロジェクト管理に置き換える発想は、Redmineの場合と変わらない。 しかし、Redmineに比べると、TracやMantisによるチケット駆動開発とAgile開発を組み合わせて運用するためには、いくつかのノウハウが必要だ。 僕の経験では、Redmineに比べるとTracやMantisは、イテレーション管理とSCM連携がやりにくい。 【1】Agile開発の基である小規模リリースを実現するには、イテレーションをBTSに実装しなければならない。 Redmineなら、バー

    TracやMantisによるチケット駆動開発の運用方法 - プログラマの思索
  • 1