事前設計とTDD - 2012-12-16 - やっとむでぽん
実はモデリングが大好きです。元々はオブジェクト指向プログラミングを勉強しているところからUMLに(自然に)興味が向き、そこからオブジェクト指向設計とかオブジェクト指向分析とかそういう脇道にそれ(脇道とか言ったら怒られる!)、仕様も設計もこれからはオブジェクト指向だ!というありがちな若気の至りもありました。デザインパターンにも転んだし、責務!ロール!コラボレーション!ってのもやったし、重厚長大なフレームワークとかもなかなか楽しいですよねえ。ねえ? 今でも概念モデルとか大好物で、上の話を聞きながらうっかりとこんなオブジェクトモデリングをしてしまったりします。 そんなわけで、プログラミングする対象の仕様を理解しながら頭の中でモデリングして設計を進めてしまうのはやむを得ません。多かれ少なかれ、なにかしらの設計が浮かんできてしまいます。 でもTDDはテストを書きながら設計をします。先行して設計してし
組み込みもけっこう末路なのかもしれない
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道 業務系に限らず、組み込み系もけっこう先行きは明るくないと思う。 メーカーの下請けでやってるようなところだと ・メーカーの予算削減で人員は減るが仕事量は変わらない ・むしろシステムの高機能化でアーキテクチャは複雑になる ・しかし一つの製品の納期はどんどん短くなる ・メーカー側もコスト面から製品に対して人員を割かなくなるので、メーカー側の社員が手が回らず下請けに丸投げしだす ・請け側の会社も仕事が少しでもあるところにスキルをあまり考えずに要員を投入する はい、デスマ。 発注側も受け側も余裕が無くなっていて、それでも請けるほうは仕事無いから請けるしか無くて、だいたい当初の想定通りのフェーズや要因で炎上する。で、年中残業やら休日出勤やらで疲弊するエンジニア。 請ける側にも多分に問題はあって、マネジメントできない人がマネジメントをし、設計
CPUのアーキテクチャをトイレに例えると | Hinemosu
おもろい。たとえ方がうまいなぁ。 消え気味なのでコピペ。 155 ：・良く分かるパイプライン ：04/04/26 17:20 ID:B6tZVOSS 「おしっこをして手をあらってでてくる」。 トイレが一室しかないと混雑時は長蛇の列ができます。 1.おしっこをする 2.手を洗う。 二段のパイプにすると、手を洗ってる間に別の人が用を足せるようになります。 トイレ一室で二人が気持ちよくなれて、効率が倍になります。 もうすこし深くしてみましょう。 1.ジッパーを下げる 2.ちんちんとりだす 3.放尿する 4.しずくを切ってちんちんしまう。 5.ジッパーをあげる 6.手を洗う 7.紙を使って手をふく 7ステージに分解すると、なんと 7人が同時に処理できます。 これがパイプラインです。 156 ：・良く分かるスーパスケーラ ：04/04/26 17:21 ID:B6tZVOSS トイレの利用はおしっこ
ソフトウェア・エンジニアから見た原発事故
私はこれまでこのブログで、今回の原発事故が「想定外の津波によって起こされた天災」ではなく、「本来想定すべき天災に対する対処を先送りして来たことによる人災」であったこと、そして、形だけの津波対策や地震対策をしたところで、「規制機関が電力業界と癒着して利権構造を作っている」という根本的・構造的な問題を抱えている限りは、同じような事故が必ずまた起こることを指摘してきた。 こんな私の指摘に対しては、「原子力の専門家でもない、シアトルに住むソフトウェア・エンジニアの戯言（たわごと）に過ぎない」と言う指摘もしばしばいただいたが、エンジニアに不可欠な「システマティックにものを見る能力」のある人であれば、原子力の専門家でなくとも、これぐらいのことは言える。 別の言い方をすれば、事故に関して公開されている限られた情報だけで、その根本の原因がどこにあったのか、そして、このまま原発を再稼働することがどのくらい危
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【西田宗千佳のRandomTracking】 UEIが仕掛ける「enchantMOON」の正体
