タグ

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

  • スクラップブック「紙」/洛西一周のウェブサイト

    スクラップブック「紙」 パソコン上で満足にものを書くには、普通の紙と比べると障壁となる ものがあまりにも多い。それを取り除くことに挑戦したスクラップブックソフト(兼エディタ)です。ホームページを効率よく取り込み、管理できます。 新着情報 サポート kamiFAN.com みけさんが運営している「紙」Tips満載のページ。 紙copiフォーラム 質問・要望をどうぞ よくある質問集

  • 『新規顧客対策はネットショッピング経験が少ないビギナー』

    堺商人的WebマーケティングプランナーのBlog 自由な商売をしてきた堺商人の心意気で、自由に自分の好きなことで商売ができるプランナーを目指して日々精進。広告業界やネット業界中心に自分の考察をまとめてみる。 富士通総研が、インターネットショッピングの利用動向について、 調査報告をまとめているのですが、 ネットショッピング経験の差で分析している点が面白いです。 対象者を2001年以前、2002~2004年、2005年以降という ネットショッピング経験履歴で3つの割付を行っています。 Web担当者Forum:富士通総研がネットショッピングの利用動向調査を発表。経験の差で多様化する利用状況 ------〈引用ここから〉---------------------------------------------- 30代、40代の男性を中心とした「実質5年以上」のベテランのこの1年のPCネットショッ

    H58
    H58 2007/09/18
  • 国連・持続可能な開発のための教育(ESD)の10年

  • ユーザーに尋ねても必ずしも正しい答えは返ってこない

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

    H58
    H58 2007/09/18
  • 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
    H58
    H58 2007/09/18
  • Life is beautiful: 私のとっておきのプログラミングスタイル

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