ソフトウェア工学と1980年のペアプログラミング - 思っているよりもずっとずっと人生は短い。
積読の山の中でソフトウェア工学の本が発掘されたら、twitterでもyuguiさんがソフトウェア工学が云々、とつぶやいていたので、読んでみました。 ソフトウェア工学 (岩波コンピュータサイエンス) 作者: 有沢誠出版社/メーカー: 岩波書店発売日: 1988/05/26メディア: 単行本 クリック: 1回この商品を含むブログ (1件) を見る 今は亡き……と思ったら、実はまだ一部は流通しているらしい岩波コンピュータサイエンスシリーズの一冊。というかこの本自体も流通してるみたいですね。 有澤誠と言えば、クヌースの翻訳でも知られている人ですが、私の中では「Bit人脈のひと」という印象が強いです。ナノピコ教室のひと、でもあったはず。まあ、要するにコンピュータサイエンス、あるいは情報工学の人で、読ませる文章を書けるひと、ですね。 文芸的プログラミング (ASCII SOFTWARE SCIENCE
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： 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.
組み込みソフトをＸＭＬが変える
このブログで「愛読書は日経エレクトロニクス」とさんざん言ってきた私の愛が通じたのか、遂に日経エレが UIEngine を取り上げてくれた。「組み込みソフトをＸＭＬが変える。開発効率向上の切り札に」という解説記事（７月１８日号５１ページ）。 携帯電話や各種家電ＡＶ機器などを含む組み込み機器のソフトウェア開発コストは上昇の一途をたどっており、ムーアの法則とともに急激に下がっているハードウェアコストとの兼ね合いから、危機的な状況にある（端末一台あたりの製造コストが下がると、固定費であるソフトウェア開発費の比率が相対的に上がるので、実質的なソフトウェア開発費のトータルコストに対する比率の上昇をさらに加速させることになる）。そのソフトウェア開発を、XML と スクリプトを使って効率化し、かつＯＳやＣＰＵに依存しない形でライブラリー化して再利用可能にしようという動きがある、という記事である。 ２０００
デザインの「悪い方がよい」原則 The Rise of "Worse is Better"
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
技術革新が有料なサービスを台無しにする - Cafe Babe
CNET Japanの「サービスを「科学」できるか--IBM研究所で討論会開催」という記事． http://japan.cnet.com/news/ent/story/0,2000047623,20075969,00.htm ここでは，社内サービスのセルフサービス化が社員の時間を奪う例が挙げられているが，これはデスクトップパブリッシングが登場した時にも同じように言われていた．また，よくあるのは，どんなメールでもMSオフィスで書いて添付してくることだ．これが情報の可読性を悪くして，さらにセキュリティの危険を招いていることを気が付いている企業は少ないかもしれない．他にも，一見凄そうに見えるけど，あまりにも重すぎて・複雑すぎて，実際には使われない技術も多い．この問題は，確かによく陥りがちな罠なのだ． 結局，どんな技術でも諸刃の剣であり，毒にもなれば薬にもなることを自覚しなくてはいけない．さらに，
業務アプリケーションのオープンソース化とビジネスケース - エンタープライズニュースの読み方
オープンソースの流れは、LinuxやMySQLなどの基盤系ソフトウェアの領域から業務アプリケーションの領域へと向かいつつある。InformationWeek誌は、"Open-Source Exuberance"と題する記事の冒頭で、Documentumの共同創業者John Newtonが、オープンソースビジネスへ転じてAlfresco Software Inc.というコンテンツ管理ソフトの会社を起こしたことを紹介している。基盤ソフトも既存ビジネスに大きな影響を与えるように、業務アプリ領域でもオープンソースは大きな地殻変動を巻き起こすことになるのか。 ビジネスモデル 記事によれば、業務アプリケーション領域のオープンソース・ビジネスに有能な人材とベンチャー・キャピタル資金が流入しているという。そのビジネスモデルの典型的なものは、まず投下資金によってソフトウェアを開発し、それを無償で提供する。そ
2005-06-01
2005-06-01 ウォーターフォール擁護論(1) 雑記／備忘 （昨日のネタと関係あるかもしれないけど、一応独立です）拙文(http://www.symmetric.co.jp/hiyama/SoftwareEngineering.htm)のなかで、「ウォーターフォール」という言葉を出しているのですが、僕は次の注釈を付けています。 念のため付け加えておくけど、… 2005-06-01 ウォーターフォール擁護論(2) 雑記／備忘 大規模開発がアジャイルの守備範囲外だとすると、規模の拡大に対処したり、大規模化してもなお有効な手法とは何でしょうか？ 寡聞にして僕は、そのような手法（問題の解）を知りません。僕の個人的感触では、規模拡大による弊害は、10人を超えるあたりで既に… 2005-06-01 ウォーターフォール擁護論(3) 雑記／備忘 では、官僚機構や文書主義が好きなのか？ と問われれば、
yohei-y:weblog: まっとうなソフトウェア工学に期待すること
naoya さんのダイアリーに端を発してちょっとだけ議論が起きている。 まず naoya さんのオリジナルのポスト。 はてなが従来のいわゆる世間一般の開発手法を採用せず Perl でアジャイルな開発手法をを選ぶ理由として、 その開発するソフトウェアサービスの性質と 動的型付け言語の開発効率を挙げている。 対してオリオナエさんは naoya さんがソフトウェア工学を軽視している(ように見える)点を、 薬学と建築工学の例を使って批判している。 吉松さんははてなのサービスとオリオナエさんの薬の例のギャップを指摘して、 いわゆるソフトウェア工学的手法に疑問を投げかけておられる。 Don'tStopMusic さんもオリオナエさんの例とはてなの違いから いわゆるソフトウェア工学(と Java)ははてなには合わないという主張だ。 ここまで読んで思ったのは、みなさんの「ソフトウェア工学」感のずれだ。 そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
http://www.isisaka.com/blog/archives/2005/08/soa_-_9.html
Oracle.com Outage
江島健太郎 - Kenn's Clairvoyance Comment on 新潮６月号の梅田望夫×平野啓一郎の対談を読んで
http://blog.japan.cnet.com/kenn/archives/000899.html
Technical documentation
http://cis.k.hosei.ac.jp/~akonoma/2003SoEnHosei.pdf
はてなブログ | 無料ブログを作成しよう
はてなブログ | 無料ブログを作成しよう
void GraphicWizardsLair( void ); //
専門家は個人の責任で情報発信するな - void GraphicWizardsLair( void ); //
http://dontstopmusic.no-ip.org/diary/20050521.html