開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
伽藍とバザール
Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳 リンク、コピーは黙ってどうぞ。くわしくはこちらを見よ。 プロジェクト杉田玄白 正式参加作品。詳細は http://www.genpaku.org/ を参照のこと。 1999/07/30版、1999/08/16訳更新, 2000年5月2日更新 原文の最新版はhttp://www.catb.org/~esr/writings/cathedral-bazaar/にて各種フォーマットで入手可能。 翻訳の pdf 版はhttps://cruel.org/freeware/cathedral.pdfにある。 翻訳の PostScript 版 (tar+gzip圧縮）はhttps://cruel.org//freeware/cathedral.tgzにある。 第 2 部 「ノウアスフィアの開墾」 (Homesteadi
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
失われた２０年－ソフト業界は変わったのか？ その５：１９９１年ごろ（１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第５回目。 今まで、第三次オンが終わったころ（１９８０年代後半）について書いてきたので、今回は、そのちょっとあとの１９９１年ごろについて書きたいと思います。 ■ダウンサイジング→オープンシステム そのころの日経コンピューターが、こんなかんじ 日経コンピューター創刊１０周年記念号 １９９１年１０月７日号の 特集が ダウンサイジング ホストなき世界の到来 ということで、このころ、ダウンサイジングが話題になる。 （アップサイジング、ライトサイジングなどといいだすひともいたけど） この流れが、オープンシ
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
UIEngineのデザイン・プリンシプル
このブログを書き始めて約１年が経つが、考えてみれば私の会社（UIEvlution Inc. 本社シアトル）がビジネスのコアに置いているUIEngineについてまだ一度もちゃんと解説していなかったことに気がついた。そこで、これから何回かのエントリーにまたがって、UIEngineとは何かどんな発想のもとに作られたのか、を書いていこうと思う。 第一回の今日は、UIEngineのデザイン・プリンシプル（良い日本語訳が無いのだが、あえて訳せば、設計理念）。デザイン・プリンシプルを持っておくことは、どんなソフトウェアを作る場合でも大切だが、特にUIEngineのようなプラットフォーム・ソフトウェアを作る場合には、しっかりと筋の通ったものを設計当初から持っておくことがものすごく大切である。 UIEngineのデザイン・プリンシプルは、ひとことで言えば、「いつまで経っても小さくて軽くてシンプルなウェブ・ア
東大での講演 - squeakerのブログ
(ちょっとだけ追記しました。その他1/25のあたりも見てみてください。) "Can programming be reinvented?"というタイトルでの発表。東工大と東大で似たような発表をしたのだが、ストーリーラインが比較的新しいため、先にやった東工大での発表には反省点がいろいろあり、それが東大での発表に生かされた形になったのは否めない、かもしれない。以下は、かなり再現性の低いメモ。詳細はさらに聞いてください。「私」はもちろんAlan Kayを指します。 近所の人から、「なんで新しいコンピュータのほうがWindowsの起動やMS Wordの起動が遅いの?」、「大きいディスクがついているはずなのに、なぜ使える容量が少なくなるの?」、「アップデートをしたら、何で再起動しなくてはいけないの？」という質問をされる。なかなか良い質問である。 私自身も、コンピュータに関する疑問がある。「なぜ、コン
Excelなんかの試験（テスト）仕様書とJunit等のユニットテストの関係（その１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） Excelなんかで、試験仕様書（テスト仕様書）を書くことって、多いと思います。 で、Junitを使う人も多いと思います。 でも、やっぱ、この業界、流派ごとの争いがおおいんでしょーかねー、 このExcelなんかで書く、試験仕様書（テスト仕様書）が、Junitで、どうやって、落とし込むのかっていうことについて、書いてくれてないケースって、多くありませんかねー。 ウィリアムのいたずらの関係したプロジェクトだけが、不運にも、そうなのか？ （たしかに、「不幸学鑑定」をやったら、けっこう不幸な人です。で、その不幸の度合いは、ドラゴンボールで言うところのヤムチャ級と出た）。 っていうことで、今日は、その関係について、独断と偏見で書いてみたいと思います。 （つーことで、これと違う意見を言う人も、
ＯＳＳがその分野にある以上、いままで書いたやり方は、認められない。訳知り顔の人に全否定されるから - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いままで、いろいろと、ＰＨＰにおいて、画面と処理プログラムを分離し、ＭＶＣを実現するためのコーディング規約と、実際のユニットテスト方法に書いてきましたが、では、実際に、この規約で、開発することが認められるか？というと、たぶん、１００％不可能です。 理由は、ＰＨＰにおけるＭＶＣのフレームワークが、各種テンプレートを使う形で、「オープンソフトとして」たくさんでてるから。。 オープンソフトで出ている場合、 ・そのオープンソフトを使わなくても、（今まで述べたように）できるとしても ・で、そっちのほうが（テンプレートのバージョンの問題がない分）、バージョン管理の問題がないとしても、 ・オープンソースのプログラムの作り方を覚えなくてすむ分、開発が短期ですみ、 ・さらに(strutsのチェック
わかりやすさと論理性を両立させる（前編） - 設計者の発言
成果物の「わかりやすさ」と「論理性」を確保することは、システム開発の全工程を通じて重要な課題だ。とくに、上流工程では「論理性」が、下流工程では「わかりやすさ」が意識されなければならない。 プログラミングにおいて「論理性」をことさら重要視する必要はない。それは重要でないということではなくて、成果物が論理的でなければコンパイルエラーになるかアベンドするかで仕事にならないくらいに本質的ということだ。プログラムのような機能的要素に限れば、下流工程成果物はほっといても論理的なものにならざるを得ない。それは成果物が基本的に「コンピュータ」向けに用意されるものだからだ。 そのためかどうか、下流工程の成果物は「人間が理解しやすいかどうか」がおろそかなものになりがちだ。いまだに「少量のトリッキーなコード」がクールと思われがちだったりするが、それはプログラムに割り当て可能なメモリー領域が小さかった時代のなごり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
