わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その3）
ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか? 「すでに決まったはずではないか」 「そう読み取れるではないか」 「いまさら言われても困る」 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。 1回目：顧客との契約時、仕様の確認をするとき 2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき 3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき .…にもかかわらず、3回目がほとんどだろ。この
「JAVA村」と「Perl村」の断絶がもたらすのは不幸なのか幸せなのか – 音極道茶室（旧アーカイブ）
私も１月１５日にブクマした「業務経歴書にPerl案件を書くと馬鹿にされる件」に関するessaさんの言及に対して、ちょっと反応しておこうと思う。 「JAVA文化とPerl文化の断絶」については、essaさんの記事と、そこからリンクされている記事でほぼ語りつくされてるのだが、「この問題の根の深さ」について少し別の視点から語っておきたい。 Java文化とPerl文化の断絶について語られる時、それはほとんど「開発者側」の視点からなのだが本当に深刻な断絶はそこよりも、「マーケット」の断絶だと思う。 世のシステム系企業を「JAVA村企業」と「Perl村企業」に分けた場合、当然どちらの企業にも「クライアント」が存在する。ところが、JAVA村企業とPerl村企業が１つのクライアントに対して競合するような場面というのは極めて稀で、「ビジネスマーケット」そのものが交わる事無く分断されているのだ。 ちょっと乱暴
プログラマーとデザイナーの境界 : 小野和俊のブログ
UIデザイン・プログラマーの話を書いたときに、何人かの方からそもそもUIデザイン・プログラマーはプログラマーではないのではないかという指摘をいただいた。 プログラムが書けるデザイナー 今となっては信じられないことだが、HTMLが普及し始めたばかりの頃にはHTMLを書くのはプログラマーの仕事で、その素案を作るところまでがデザイナーの仕事だった時代がほんの少しだけあった。すぐにデザイナーがツールの活用やスキルの習得によってHTMLを自分で書くようになって、動きのないWebページのデザインはデザイナーが、掲示板のようなCGIプログラミングが必要な箇所はプログラマーが担当するようになった。そしてさらにその後すぐに、JavaScriptやCGIを自分で書くことができるデザイナーが現れた。 ユーザビリティ・デザインの対象範囲 ソフトウェアの手触りをデザインする際には、静的な画面デザインだけでなく、ユー
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
Life is beautiful: 日本語とオブジェクト指向
先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」
Teach Yourself Programming in Ten Years 日本語訳
以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日本語訳である。 本翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん：誤訳の訂正 三好博之さん：誤訳の訂正 竹中明夫さん：2001年7月改版分の訳、誤訳の訂正（共訳者にクレジット） Toshihiko Ono さん：誤訳の訂正 アクビさん：訳注３に関する情報 どうしてみんなそんなに急ぐの？ どの本屋に足を運んでも、『7日で学ぶ Java』といったハウツー本を見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむ本が無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W.
druby.orgの方から来た人カコイイ: オブジェクト倶楽部クリスマスイベント, しばらくは http://kakutani.com/ でアクセスしてもらったほうがよいかも - 角谷HTML化計画(2004-12-09)
■1 オブジェクト倶楽部クリスマスイベント 当日スタッフ兼ライトニングトークス発表者、の予定。 ライトニングトークスは「見える化」がお題ということで、ちょっとハッスルして昨日から資料をつくりだしたら、60%ぐらいの仕上りでスライド30枚超えちゃった。持ち時間5分しかないのに……。また銅鑼を鳴らされてしまいそうな悪寒。 ライトニングトークス資料: 「見える化」の実践を「見える化」(PDF) けっきょく、48枚スライドを用意して、45枚めくったところで時間切れ。最後のひとネタを披露できず、少し心残りを感じた。けれど、例によって一部には好評だったようで、そこだけが救い。本日の献立は以下2篇: バーンダウン・チャートの紹介 シーズン2 〜The Burndowns: eXperienced〜 eXtreme Feedback Devicesの導入 〜XFDs: Installed〜 Mr.フライパ
「見える化」でソフトウェア開発！ 〜オブジェクト指向 実践者の集い(第 3 弾) 参加レポート〜 sooey
［レポート］ 「見える化」でソフトウェア開発！ ～オブジェクト指向実践者の集い(第 3 弾) 参加レポート～ 1．はじめに 昨年の 12 月 9 日、オブジェクト倶楽部主催によるイベント「オブジェクト指向実践者の集い」が行われました。「オブジェクト指向実践者の集い」はオブジェクト指向を現場で実践している、あるいは実践しようとしているエンジニアに役立つよう「現実的なオブジェクト指向とは何か」、「オブジェクト指向を見直してみよう」をテーマとしています。今回で、このイベントは 3 回目となりました。 クリスマス企画という事で会場にはツリーが置いてあったり、スタッフのみなさんがサンタクロースの帽子をかぶっていたりで、和やかな雰囲気でした。 今回のテーマは「見える化」です。ソフトウェアの世界は見えないものが非常に多いです。そして「見えない」ことにより、ソフトウェア開発では様々な問題が出てきます。例え
切込隊長BLOG（ブログ） - 本当に技術が必要とされる現場にgeekがいない
以前、ネットをふらついていたらこんな記事があった。 http://fragments.g.hatena.ne.jp/another/20051109/1131545150 伊藤直也氏というと、顔はゴツいけど著名で実力のあるネット技術者であり、彼をDISりに来た人がDISる前に「あー、どうせ俺もうだつの上がらないIT技術者ですよ」とか萎えてしまうほどの力量の持ち主である。 http://d.hatena.ne.jp/keyword/%a5%a2%a5%eb%a5%d5%a5%a1%a5%ae%a1%bc%a5%af だいたいそういう人は、技術的なモチベーションを維持しやすい最先端企業やサービスにいる。技術者が技術者同士切磋琢磨できる環境にあることで、最新の情報に触れ、最高のアイデアを実現できるポジションにいようとする動機があるのだろう。称賛されうる仕事で己の能力を十全に活かしたいとい
プログラマーの格言（盗作多し）
プログラマーの格言（盗作多し） 頼む、９６になるまで盗作を続けさせてくれ プログラマーの格言（盗作多し） 一日は２４時間ある。 今日中という意味は明日の朝までという意味である。 プログラマーの格言２（盗作多し） プログラムは思った通りに動かない。書いた通りに動く。 プログラマーの格言３（盗作多し） 要求仕様はプログラム完成後に完結する。 基本仕様は完成品を顧客が見てから決定される。 詳細仕様は使用者がプログラムを動かしてから固まる。 プログラマーの格言４（盗作多し） 私は、ソフトウェア設計には 二つの方法があるという結論に達した。 一つは、欠陥がないことが明らかなほど単純にする方法である。 もう一つは、明らかな欠陥がないほど複雑にする方法である。 C.A.R.Hoare プログラマーの格言５（盗作多し） コードは開発現場で書くんじゃない！ 納品先で書くんだ！ デバグは納期前にするんじゃない
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
