タグ

devとdevelopに関するf99aqのブックマーク (5)

  • kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥

    Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方(ビジネスモデル)に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー(経営者)にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい!・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

    kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
  • 青木淳「オブジェクト指向システム分析設計入門」

    はじめに このはオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれたです。プログラムのコードや難しい数式などを排除してあり,図と文章によって基概念や適用技術を平易に解説しています。オブジェクト指向技術数学(形式)ぬきで探求する試みといえるでしょう。 来,オブジェクト指向技術を,瓶から瓶へ水をもらさぬように,正確に伝えるには,数学(型理論)を必要とします。数学的形式化が行われていないと,オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ,この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし,数学的形式化の苦しみときたら並大抵ではありません。特に,後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません

  • How to Write Maintainable Code 日本語訳

    以下の文章は、Bram Cohen による How to Write Maintainable Code の日語訳である。 翻訳文書については、福盛秀雄さんと竹中明夫さんから誤訳の訂正を頂きました。ありがとうございました。 ソフトウェア技術者は、自分が書くコードがどのようにあるべきか分からず悩んでいる。よく知られたエッセイ「悪い方がよい」(訳注:日語訳)がその良い例である――どうして悪いほうがより良くなれるの? やっぱり悪いほうが悪いんじゃないの? さらにややこしいことに、「悪い方がよい」の話は、それが主張しようとしている内容とは正反対の議論の中で引き合いに出されることが多い。 問題は、みんながコードの「美しさ」を判断するのに非常に多様な、また往々にして相反する基準を採用していることだ。美的感覚よりも客観的な、コード品質に対する基準が明らかに必要である。 僕としては、メンテナンス性に

  • デザインパターンFAQ

    翻訳: デザインパターン・メーリングリスト有志 原文は Doug Lea<dl@cs.oswego.edu> によってメンテナンスされています。 原文の最終更新は2000年11月です。 この文書は通常の意味でのFAQではありません。 この文書には、 patterns-discussionメーリングリストで議論されてきたトピックの 非常に短いサマリーがQ&Aの形式で含まれています。 項目の取捨選択および内容には管理者の主観的な判断が入っています。 このFAQは不定期に更新されます。 パターンに関する情報は、 The Patterns Home Pageを参照してください。 そこにはオンライン上のパターンへのリンク、 パターンに関する論文、パターンを扱った書籍の説明、 カンファレンスの一覧、 そしてパターンに関連したメーリングリストが含まれています。 「パターン」という用語によい定義がないのは

  • 道具箱の整理

    はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ1ヶ月ほど、私的Webサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね~」と話していたのが、非常~に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数(アクティブな人)が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、

  • 1