RedmineのER図 - プログラマの思索
RedmineのER図を作る方法が公開されていたのでメモ。 【元ネタ】 redmineのER図を生成してみた | ぷろぐらま Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。 だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。 Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。 「強制されたサロゲートキー」の事例を眺める: 設計者の発言 複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。 多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。 つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。 DOAの立場の人がサロゲートキ
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない - プログラマの思索
「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。 ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。 以下は書きかけ。 【参考】 第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話” | GiXo Ltd. 第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章） | GiXo Ltd. ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間 【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。 「過剰と破壊
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ - プログラマの思索
Redmineの運用の現場を見ていると、チケットをストックとして見る場合とフローとして見る場合で観点が異なるように思えた。 ラフなメモ書き。 【1】Redmineを運用し始めた時に、チケットよりもRedmineプロジェクトの分割に重きを置いたり、チケットをWBSと一体視して、1チケット＝1担当者で運用する現場を見かける時がある。 たいてい、上手く回っていない。 本来のチケット駆動開発では、チケットを経由して一つの作業を複数人が分担してやり取りする。 その流れがチケットで表現されるから、今誰がボールを握っているのか分かるのに、チケットをWBSで固定化してしまうと、手戻り作業が発生するたびに、現状を把握しにくくなる。 このアンチパターンを「WBS駆動」「担当者固定」と僕は呼んでいる。 【2】@akahane92さんも言っていたが、Redmineでは、チケットのコメントが長くなるような運用の方が
ERPの落とし穴part2～業務の裏には会計あり - プログラマの思索
ERPの落とし穴part1～SW開発ではない。要求開発だ！の続き。 「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を非常に参考にしているので、全てが僕のオリジナルの考えではないので注意。 【1】業務の裏には会計あり。業務データは必ず仕訳データに連携される。 業務システムの裏には必ず会計システムがある。 Webで作っていても、メインフレームで動く会計システムと連携できなければ、ただの箱に過ぎない。 会計システムと連動できて初めて、業務コストや売上が計算出来るし、更には売掛金管理や請求管理で経理担当者の仕事もサポートできる。 例えば、「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、販売業務では、受注→出荷→売上→請求→入金のような業務フローがあるだろう。 業務データの裏には、仕訳デー
なぜ超高速開発が話題になるのか～キーワードはビジネスルール管理システム(BRMS) - プログラマの思索
最近なぜ超高速開発が話題になるのか、何となく分かった気がした。 ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 超高速開発先進国、知られざる韓国企業の実態 - サムスン電子に見る「威力」：ITpro NC特集 - 「超高速開発」が日本を救う：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第3回 ビジネスの俊敏性を実現する：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第4回 スマートなシステムを生み出す：ITpro ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経 ビジネスルールとビジネスプロセス（その1） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その2） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その3） | 株式会社ＫＢマネジメント ビジネスルールと
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
業務フローで非同期キューが現れる理由 - プログラマの思索
プログラムを書くよりも「絵を描いて説明してくれ」という仕事が多くなって、いつも感じる疑問は「業務を分析する時の基本的な観点は何か？」ということ。 その疑問に対する解答のひとつとして、僕が何度も読み返している記事は下記の３つ。 １・ワークステートエンジンとは何か（はぶさんの記事） ワークステートエンジンとは何か～Long Way To S2Buri～ その１ ワークステートエンジンとは何か～Long Way To S2Buri～ その２ ２・SOAの実現: サービス設計の原則～柔軟なITのためのサービス設計（IBMの記事） 【１】業務フローの分岐が業務分析を難しくする 大抵の業務システムのプログラムは、そんなに難しいアルゴリズムを使っているわけではない。 でも、難しくなる理由は、業務フローを制御する分岐処理がデリケートだから。 分岐にはフラグとIF文が組み込まれているだけなのに、カスタマイズ
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
RedmineとHudsonの関係付け - プログラマの思索
Redmineのチケットとバージョン管理を連携できる機能は、変更管理のインフラを提供してくれる。 変更管理について考えたメモ書き。 【元ネタ】 PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1】変更管理が必要な場面 SEと呼ばれる人の仕事を眺めてみると、要件や仕様に関する変更管理プロセスに従事している時が多いことに気付く。 SEの一番の仕事は、顧客から要件を聞き取り、仕様書としてまとめて、開発者へ仕様を提示する。 つまり、業務のインターフェイスを設計すること。 設計工程で完璧な仕様書が作られる可能性は低い。 むしろ、要件漏れ、設計漏れが開発や結合テスト、あるいは受入テストで大きなリスクとして発覚することが多い。 昨今のシステム開発では、SeasarやRailsのような優れたフレームワークがあり、JUnitのようなテストユニットがあるので、単体テストをクリア
Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索
Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 ＃以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組合せテストにおける因子と水準はどちらを最優先で考えるべきか - プログラマの思索