「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
Geekなぺーじ：エンジニアは下らない質問をする
「バナナはおやつに入るんですか？」という質問をしたことがあるエンジニアは多いと思います。 私も真っ先にそのような質問をした覚えがあります。 で、実際にバナナを持ってくる人がいるかというと、私は見たことがありません。 エンジニアって一般人から見ると変な、もしくは下らない質問が大好きな人種なのではないかと思う事があります。 エンジニアというよりもプログラマかもしれませんが、全ての事をswitch case文で考えて、条件分岐の白黒をはっきりさせたがってしまうのではないかと思うのです。 以前、マンション営業をする友人に「職業がエンジニアな人がお客さんだと面倒なときがある」と言われた事があります。 最後に契約書を確認する際に、非常に細かいところを確認したがって面倒であるそうです。 (私は細かく確認しない大多数の人の方が間違っているとは思いますが。。。) 細かい話になってくると、例えば受け渡しの前に
プログラマの権利宣言
Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基本的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の
非テキストプログラミングとLLの次 - Ringo's Weblog: 2007年03月07日 アーカイブ
非テキストプログラミングとLLの次 LILYというプログラミング環境の紹介ビデオをみて、考えが少し進んだ。 1. 視覚的プログラミングの目的設定は、プログラミングを簡単にすることというよりは、 多人数同時プログラミングをすることに置いたほうが良い可能性があるな、ということ。 2. リンクとノードを使った視覚的プログラミングは、 極めて限られたDSLにしかなり得ないだろうということ。 3. 視覚的プログラミングの研究で得られたアイデアは、 独自の開発環境ではなく、テキストエディタや、テキストを使う言語処理系の 仕様に反映していくのが良いだろうということ。 4. LLの次に必要なのは視覚的プログラミングではなく、 共同作業や非同期的変更を前提として設計された、 テキストベースの、不定・動的・非同期プログラミング環境だろうということ。 5. 上記のような環境ができて初めて、関数型言語が花開くかも
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
金型プログラマと製品プログラマと - 設計者の発言
業務システム開発の世界では、案件毎のプログラミング（従来の意味での、狭義のプログラミング）を減らすような工夫が発展し続けている。コードを自動生成させたり、設定ファイルの編集でシステムの動きを指定できる。そんな実装用フレームワークの発展が止まらない。コーディング量を減らすための工夫をしたがらないのは、工数ベースで稼ぐ派遣業の経営者くらいだろう。 そのような技術革新の結果として、以前にも書いたように、システム開発での分業体制が変化する。ある種のプログラマは個々の開発案件ではとんと姿を見せなくなる。彼らは「別室」でフレームワークの開発に従事しているからだ。フレームワークは個々のシステムを生み出す「金型」とか「工作機械」のようなものなので、彼らを「金型プログラマ」と呼ぼう。いっぽうの、個々の開発案件のプロジェクトルームで働いているのは「製品プログラマ」だ。彼らは「金型プログラマ」が開発したフレーム
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
プログラム・デザイナー宣言 : 小野和俊のブログ
(プログラム・デザイナーと職人プログラマーの続き) かつて、 「すごいプログラマー」は みんな職人プログラマーだった。 今は、 「すごいプログラマー」の 多くはプログラム・デザイナーだ。 拡張の快適さ といったものだから、 主観的にしか評価することはできない。 プログラム・デザイナーの 仕事の本質は、 つくること以上に デザインすることだから、 今のソフト業界がファッション業界に似ている というのは当然のことなのかも知れない。 Binary 2.0 という考え方が出てくるのも、 こうしたことが背景にあるのだろう。 プログラム・デザイナーと 職人プログラマーとは、 いがみ合いやすい。 あいつは機械のことがわかっていない。 あいつは動けばいいと思っている。 あいつの書いたコードは誰もメンテナンスできない。 あいつはあんなことも知らない。 この種の対立は不毛である。 プログラム・デザイナーよりさ
遅いコードを貯蓄する - Backnumbers: Steps to Phantasien
2005-08-21 遅いコードを貯蓄する 私は仕事柄, 書いたコードに実行速度を要求されることがある. 本当はいつも要求されていて, たまにそれに応えるという方が正しいかもしれない... とにかく, 権力者(上司, 顧客, 同僚)から "遅いので速くしろ" というお言葉を日常的に頂く. とはいえできる範囲の高速化は既に済んでいる. 無い袖は振れない. まわりからの圧力を前にすると, 高速化の余地あるコードがある種の資産に思えてくる. 高速化の "余地" にも色々ある. 直せは確実に速くなる性質の良いもの. 複雑さ故に速くなる "かもしれない" ように見える 不確実性の高い不良債権, まだプロファイルをとっていない未公開株のストックオプション, など. そこで, 優良な財をなす投資の方法 ... つまり遅くてかつ簡単に高速化できるコードを書く方法を, いくつか提案しておく. アクセサ変数を
開発者が楽しく仕事できる環境とは:近藤淳也の新ネットコミュニティ論 - CNET Japan
立って会議をするだけでなく、はてな社内では他にも色々なことを試みています。その中でも、開発者が楽しく仕事ができるように、という観点でいくつか紹介してみたいと思います。 まずはペアプログラミング。これは、2人1組になってプログラムの開発を行うスタイルで、XP（エクストリームプログラミング）のプラクティスの一つとしても提唱されているものです。 2人でプログラムを開発するというのは、1人がプログラムを書き、もう一人が横からそれを見ている、という方法です。この方法を聞くと、1人がそれぞれの作業を行うよりも作業量が2分の1になってしまいそうな気がするものですが、実際はそれぞれが別々の作業をするよりも効率が上がる、という興味深い逆説的な現象が発生します。 ペアプログラミングの様子。こういうときはなぜかコーラが似合います。 なぜ2人1組でプログラミングをする方が1人ずつでやるよりも効率が上がるのでしょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Efficient data transfer through zero copy
「現物主義」に基づいたソフトウェア開発手法