タグ

Philosophyに関するshomaのブックマーク (8)

  • スラッシュドットジャパン: 竹内 郁雄氏からのコメント - Binary Day 2008

    1 はじめに 成立ちに2000年以上の時代差がある老子のTaoism※1とプログラミング※2に直接の関係があるというのは,強引にすぎるというものだが,それにしても,多くのコンピュータ科学者や技術者 (実は我々も含まれるのだが) が老子のTaoismの引きつけられて,それをなんらかの形で明言しているのは単なる偶然の一致ではあるまい.西欧文化の根源であるギリシャ哲学を除いて,このような古来の (非西欧的) 哲学がコンピュータの分野で,比較的多く論じられたり,引用されたりすることはまれであろう. 稿では,我々自身とTaoismの (主に偶然による) 関わりと,我々に目についたTaoismとコンピュータ科学との関わりの事例についていくつか紹介するとともに,こういった一見不思議なリンクが一体なにに根ざしているか,若干の考察を加えたい. これからプログラミングは産業的にも技術的にもある意味で不透明な

  • http://d.hatena.ne.jp/tumf/20080409/1207728796

    shoma
    shoma 2008/04/25
    3番目のルールと社長の言葉
  • Google Engineering Philosophy

  • はてなブログ | 無料ブログを作成しよう

    東大生でない中川淳一郎さんが駒場寮で得た人生訓(私と東大駒場寮 3) 駒場寮の北寮9Bの部屋、「基礎科学研究会」、略して「KKK」の部屋 予備校の講師に連れられて、駒場寮に出入りするように 「代わりに面接受けろ」入寮の面接は「替え玉」で突破 「経営と文体の基は寮での読書で培った」 東京大学の駒場キャンパス(東京都目黒区)にか…

    はてなブログ | 無料ブログを作成しよう
  • Google - Google について、Google の文化、企業ニュース

    Google の使命は、世界中の情報を整理し、世界中の人がアクセスできて使えるようにすることです。

    Google - Google について、Google の文化、企業ニュース
  • プログラミングの6大10項目リスト

    Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの「エゴレスプログラミングの十戒」 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに「空手」を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯

  • Geekなぺーじ:UNIX哲学の基本原則

    「Basics of the Unix Philosophy」でUNIX哲学の基原則がまとめられています。 UNIXの設計思想として紹介されていますが、多くは普通のソフトウェアを設計する場合にもあてはまると思われます。 1. Rule of Modularity(モジュール性): きれいなインターフェースで接続された、簡潔な部品を書きましょう。 2. Rule of Clarity(明瞭さ): 明瞭さは賢さよりも良いです。 3. Rule of Composition(構成): 他のプログラムと接続できるようにプログラムを設計しましょう。 4. Rule of Separation(分離): ポリシーとメカニズムを分離しましょう。エンジンとインターフェースを分離しましょう。 5. Rule of Simplicity(単純性): 単純化された設計をしましょう。複雑さは必要な時だけ追加しま

  • Martin Fowler's Bliki in Japanese - 技術的負債

    http://www.martinfowler.com/bliki/TechnicalDebt.html システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方(将来、変更が困難になることは分かっているよね)。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は(ファイナンスの負債と同じく)技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リ

  • 1