タグ

2006年6月28日のブックマーク (8件)

  • Hypertext Transfer Protocol -- HTTP/1.1

    Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June 1999 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvem

  • Engadget | Technology News & Reviews

    Doctor Who is back, louder and more chaotic than before

    hiyang
    hiyang 2006/06/28
    3Dデスクトップより2Dコンテキストメニュに感心
  • 要求仕様戦争(その1)

    ■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100%はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ(しかも部分的だ)。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体

    要求仕様戦争(その1)
    hiyang
    hiyang 2006/06/28
    なぜ紛糾するのか
  • 要求仕様戦争(その2)

    ■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか(書いた人も)分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる

    要求仕様戦争(その2)
    hiyang
    hiyang 2006/06/28
    トリアージ開発 - デスマーチより
  • スクラムは現実解 (arclamp.jp アークランプ)

    アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebやで探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠(土日を含む30日間)を基準とする。 チームは少人数(7人前後)で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで

  • フリーランスのススメ (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨年12/20に個人事業主になり1年が過ぎました。思ったよりも楽だったし、なにより楽しかったというのが率直な感想です。 楽だ、と感じるのは、良い出会いがあったため安定した収入を得られたためです。楽しかったのはブログ、雑誌、講演、案件を通じて多くの方と知り合い、いろいろな話ができたことです(そして脂肪が溜まりましたw)。 フリーランスは企業起業家ではない 「雇われない生き方」を選んだ理由。たぶん、仕事を出す側と対等の立場になりたかったから。つまり、やりたくない仕事をやらない権利が欲しかったのだと思います。 すごく重要なことですがフリーランスは企業起業家ではありません。あくまでも自分の能力を提供し対価を得る人間です。ここを勘違いしないでください。 僕は案件に組み込まれ、

  • Ajaxの"A"で気づく技術論 (arclamp.jp アークランプ)

    AjaxといえばAsynchronous JavaScript + XMLの略なので、頭の"A"は、"Asynchronous(非同期)"の意味です。 ある方に「AjaxのAって非同期だよね?技術的にはどうなってるの?」と聞かれたので、「あー、技術的には軽量の同期技術(http)を使っているんですが、ユーザーさんの感覚と非同期になっているだけなんですよ」と答えました。 ※3/6追記。コメントいただきました。僕の理解は間違っていて「画面描画と通信」というクライアント内での処理がマルチスレッドによって非同期になっているのを"Asynchronous(非同期)"と考えるのが正しいです。というわけで、この後の議論は僕の誤解に基づく論理展開としてお楽しみくださいませ。 後になって考えてみたのですが、これってけっこう重要なことだなと。 非同期を非同期技術で実現しようとするから高くなる 梅田さんの「ウ

    hiyang
    hiyang 2006/06/28
    レスポンス3秒を2秒にする努力をするぐらいなら、3秒待てるように砂時計を出した方がよっぽど安くて安全
  • Bing

    「ノウサンゴ」オーストラリア, グレート・バリア・リーフ -- Stuart Westmorland/Corbis