[B! software] ninjinkunのブックマーク

gihyo.jp -「Joel on Software」Joel Spolsky：翻訳エッセイ編―プログラムマネージャになるには

Pick Up Entry from "Joel on Software" 翻訳エッセイ編―プログラムマネージャになるには優れたプログラムマネージャを擁しているということは、素晴しいソフトウェアを生み出すための秘密の公式だ。あなたのチームにはそういう人がいないかもしれない。ほとんどの開発チームには優れたプログラムマネージャがいないのだから。 Charles Simonyi は優れたプログラマであり、WYSIWYGワープロを生み出し、Martha Stewartと付き合い、Microsoftの株で何十億ドルという金を手にして宇宙にまで行った男だが、彼は大きなソフトウェア開発チームの管理における『人月の神話』（⁠注1）の問題を解決しようと、超優秀なプログラマを1人置いて最上位の関数を書かせ、下位の関数の実装は必要に応じてチームの下っ端プログラマにやらせるという方法をとった。この超優秀なプログ

ninjinkun 2009/07/27

software

リンク

きまぐれ日記: 「ハードウェア」プログラマと「ソフトウェア」プログラマ

プログラマ・ソフトウェアエンジニアと呼ばれる人間には、 2つのタイプがあるような気がしています。ひとつは、もともと機械いじりやハードウェアが好きな「ハードウェア」プログラマ、もう一つはその反対の「ソフトウェア」プログラマ。それぞれどういう特徴があるか、独断と偏見でまとめてみました。 (私自身ハード出身なのでそちらに偏重していますw ) 「ハードウェア」プログラマ「最適化」という言葉が好き外的な制約(メモリ/速度/ディスク)がある方が燃えるし、真の能力を発揮できる逆に制約がないと何していいのかわからず、平凡なアイデアしか思いつけない開発言語は、制約から決定する O(n) の計算量でも、その定数項を気にする専用ハード好き (地球シミュレータ, メーンフレーム) 定量評価ができないような仕事は興味ない固定長データバイナリデータ再帰なんてもってのほかスピード狂 CPUがどれ

ninjinkun 2009/07/20

リンク

空気のようなソフトウェアのつくりかたに迫る - 武蔵野日記

Word ＋ IME 2000に迫るを読んでいろいろと考える。taku さんのファンに支えられるプロダクトとユーザにdisられるプロダクトを読んで、「ポジティブなファンの応援は確かに励みになりますが、改善点を正直にぶつけてdisってくれるユーザ(not ファン)を大事にしていきたいと思います。良くも悪くも言われないんだけど、誰もが空気のように使っているというのが私の理想のプロダクトです」とあって、そうだなぁ、と思ったり。安達：そうなんです。ユーザビリティ・ラボのテストでも，初心者の人はどうしても変換中の文字列に対してマウスを使ってしまって，変換中の文字列が全部消えてビックリ，となる。そこで，変換中の文字列に対しても，確定後の文字列に対してと変わらないマウス操作を可能にしよう，と。藤本：その一環として，見た目的にも，変換中の注目文節が反転する表示をやめました。代わりに太い下線が引かれます

ninjinkun 2009/07/18

im
software

リンク

設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ

私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、頭脳間距離。時間的距離。の２つ。頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ