「ＤＢ構造の前にＵＩを決める」というアンチパターン - 設計者の発言
画面定義書があるのにまともなＥＲ図がない。業務システムの開発プロジェクトがそういう状況を一瞬でも経由したのであれば、大きなリスクを抱えていると考えたほうがいい。小さな案件でない限り、デスマーチに陥る公算が高い。 喩えるなら、高層ビルの「上モノ」の図面が詳細に出来上がっているわりに「土台」の図面がないようなものだ。その点を問われ、 「ああ、ボーリング調査も土台設計も後でしっかりやるから大丈夫です。土台の図面なんてほら、専門的すぎてお客さんが見てもピンと来ないじゃないですか。お客さんが知りたいのは土台とかではなくて上モノのデザインなんですよ。なんといっても顧客の納得感が大事です」 なんて言う建築士はいない。「顧客の納得感」が重要でないと言うつもりはないが、それだけを基準にして高層ビルを設計できるのなら苦労はない。専門的な仕事の難しさは、顧客には見えないし想像もできない膨大な部分の整合性をはかる
ymlでERDを書けるymldotを作ったのですが... - I am Cruby!
ERD, Rubyそういえば，ちょっと前に「ymldot」というのを作りました． なに？(What?)どうやって？(How?)楽々ERDレッスン 第1回：「お持ち帰りご注文用紙」編：CodeZineで紹介されているERDを書くときに # reference http://codezine.jp/article/detail/154?p=1 config: font: MSUIGOTHIC.ttf tables: - name: 顧客 columns: - 名前 - 電話番号 foreignkeys: has_many: - 注文 - name: 注文 columns: - 注文数 - name: 商品 columns: - 名前 - 金額 - 税 - 商品区分 foreignkeys: has_many: - 注文 - name: 商品カテゴリ columns: - 商品カテゴリ名 f
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
