無駄な詳細設計書を滅亡させるための処方箋 - aike’s blog
昔は「詳細設計書なんてアホなもん作ってもプログラミングには何の役にも立たないんだよふぁっきゅー！」と言い続けるのが、詳細設計書を滅亡させる手段だと思っていたけど、どうも事態はそんな簡単じゃぁないっぽい。 じゃあ一体どうすればいいのかってのはマッタク思いもつかない。まぁカンタンに無くなるもんだったらとっくの昔に滅びてるわけだしねぇ……もし、解消することが出来たら、ないし処方箋を思いつくことができたら、いつか blog に書きたいです。 詳細設計書が滅亡しない理由 - kagamihogeのblog SIerが作らされる詳細設計書（内部設計書とかプログラム設計書などと呼んだりもします）の評判は相変わらず悪いですね。このへんについては前からいろいろと考えてたことがあるので今回まとめてみます。コーディング時点で必要になる文書を極限まで減らしつつ、ウォーターフォール式の開発で納品物もきっちりそろえる
架空の業務システム作ってSIer釣ろうぜｗｗ - aike’s blog
みたいなウェブ広告が出ていました。 こんな感じでシステムを開発するのかと一瞬目を疑いましたが、たぶん違います。 1 ：以下、名無しにかわりましてVIPがお送りします ：2010/07/12(月) 03:06:26.90 まずは、システム名 >>10 2 ：以下、名無しにかわりましてVIPがお送りします ：2010/07/12(月) 03:07:42.12 システム要件 >>20 開発言語 >>30 3 ：以下、名無しにかわりましてVIPがお送りします ：2010/07/12(月) 03:08:12.48 受注金額 >>40 開発人員 >>50 920 ：以下、名無しにかわりましてVIPがお送りします ：2010/07/16(金) 23:22:52.30 後から判明する重要な要件 >>950
プログラマーが知っておくべきうつ病の知識 - aike’s blog
少し前にITproにプログラマーは「こころの病」にかかる比率が高いという記事が載っていましたが、あらためて言われるまでもなくプログラマーがストレスで精神を病んで離脱するケースは自分の周りを見ても非常に多いです。こんな状況であればプログラマーに対する危険手当やプログラマー専用うつ保険とかあっても良いと思うのですがなかなか社会は変わらないようです。 このような状況に対抗するにはプログラマー自身が自衛のために知識を得ることだと思います。プログラマーの武器は知識であり、ハックする好奇心なのだから、あらかじめ十分な知識を身につけて不当なストレスに対して有利に戦いをすべきなのです。 １．判断力低下は想像以上に怖い うつで一番恐ろしいのは、気分が憂鬱になることではなく、判断力が低下することです。 判断力が落ちるとどうなるかと言うと、自分が健康なのかどうか判断できなくなり、仕事を休むべきなのかどうかで判断
ロジックをDBMS側に寄せるデザインパターン - aike’s blog
O/Rマッパー（ORM）かSQLか、という話が一部で盛り上がっていたので追いかけていました。 ORMについては以下のような見方をすることもできます。 「最初からあらゆる要素をオブジェクト指向で設計、実装すると決めた新規開発システムならばORMは有力な採用候補」 「非オブジェクト指向で設計、実装されたシステムにORMはあまり向いていない」 なので、すでに存在しているデータベース上で別の新しいシステムを構築するような場合は、ORMはあまり向いていないと思います。 O/Rマッピングツールに対する誤解をときたい - ITは芸術だ 引用したエントリはとても冷静にORMの利点を説明している良記事です。 この記事の内容には全面的に賛同しつつ、自分としてはSQL側からちょっと書いてみたいと思います。 以前、試しにクエリに付随するロジックをできるだけDMBS側（SQL）に寄せるようにして開発したことがありま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
