タグ

2007年9月17日のブックマーク (6件)

  • 科学と哲学、部分真理と全体真理

    jar2
    jar2 2007/09/17
    生命現象を部分的要素に還元する立場は要素主義。生命現象は諸要素の全体的な関連に基づくことを全体論
  • 相補性原理について

    「相補性原理」は量子力学の父ニールス・ボーアが1927年 に提唱した原理です。 この原理を厳密に定義することは難しいのですが、要約すると「すべての物事には二つの側面があり、それぞれの側面は互いに補い合ってこそ、ひとつの実在について記述することができる」というもので、ボーアはこの相補性原理と中国の古代哲学である陰陽思想とが、よく似ていることに気付いていました。「一方を否定すれば、他方も成立し得ない相互依存の関係性」と解釈すれば、仏法で説く「不二」の思想に近いものでしょう。 相補性(Complementarity)という言葉は、ボ−アが使用して以来その意味の「あいまいさ」を指摘されながらも、科学や哲学の分野で多種・多様な使われ方をしています。 科学の公理に因果律がありますが、因果律は19世紀の科学の公理であって、今日の科学を導く公理は、因果律のみでは十分でなくなりました。 ”な

    jar2
    jar2 2007/09/17
    一方を否定すれば、他方も成立し得ない相互依存の関係性。仏法で説く「不二」の思想に近い。原因と結果の間にも相互依存性があり、因果律自体が「相補性原理」の一部と見ることが出来る。
  • ユーザーに尋ねても必ずしも正しい答えは返ってこない

    今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった(たとえばカスタム・フォームが良い例)。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない(こういう人たち

    jar2
    jar2 2007/09/17
    ユーザーを徹底的に観察すること
  • アイリスプラザ ≪20×30cm◆タテ・ヨコ両用!≫ホワイトボード PWB-23 ブルー - Yahoo!ショッピング

    jar2
    jar2 2007/09/17
  • LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found

    2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ

    LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found
    jar2
    jar2 2007/09/17
    コピペを恐れるな。一つ書いては一つ動かせ。
  • Life is beautiful: 私のとっておきのプログラミングスタイル

    404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は7月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、当は大幅な設計変更をすべきなのに応急処置で

    jar2
    jar2 2007/09/17
    仕事を「タスク」に細分化タスクはさらにマイクロタスク(今日やる分)に細分化。階段を一段一段踏みしめながら登るように、チェックインのたびにテストを繰り返しながら、丁寧に丁寧に一段づつ仕事を積み重ねて行く。