感覚的なイメージで考えられがちな品質をさまざまな角度からのデータで分析する傾向がますます強くなっている。品質について再考してみよう。 2005年はテストに関する書籍や専門誌が数多く発刊され、開発の中で脇役のように考えられていたテストの存在が一躍注目されるようになりました。 一方、海外の多くの企業および国内の一部の企業では、品質についての責任を持つCQO(Chief Quality Officer:最高品質責任者)という役職が設置され、CTO(最高技術責任者)が技術部門の総責任を持つように、CQOが品質に関する総責任を持つようになっています。 品質の低下や低い品質がビジネスに与える影響をリスクとして考えることが一般的になり、感覚的なイメージで考えられがちな品質をさまざまな角度からのデータで分析する傾向がますます強くなっているわけです。しかし、品質とはユーザーの満足であるという観点から考えた場
Venkman JavaScript Debugger FirefoxのExtention. JSUnit メソッド 内容 assert([コメント], booleanValue) assertTrueと同じ assertTrue([コメント], booleanValue) booleanValueがtrueか assertFalse([コメント], booleanValue) booleanValueがfalseか assertEquals([コメント], value1, value2) value1 == value2か assertNotEquals([コメント], value1, value2) value1 != value2か assertNull([コメント], value) value == nullか assertNotNull([コメント], value) value
業務システム構築プロジェクトでは、業務部門の理解と協力が不可欠だ。これらの人々にシステム開発の意義、そしてシステムというものの特性などを説明することを省略してはいけない。 不良システムが業務に及ぼす影響を説明する システム開発の成功には、上司や業務部門の理解や協力が絶対に必要です(本連載では、プロジェクトチームの上司はITに不明であることを前提にしています)。 こうした理解・協力を獲得するには、「不良プロジェクトは不良システムを生み、不良システムを使う業務は未来永劫、業務効率の向上など望めない」という主張が効果的です。プロジェクトチームは折に触れ、何度もこの主張を繰り返すべきです。 不良システムは業務を妨害する 各業務部門にとって不良システム(すなわち、利用するのに我慢を強いるようなシステム)が業務効率の向上に寄与しないことは当然であり、場合によってはトラブルを頻発させるなど業務効率を悪化
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
「データベース」は2006年、サイトサービス指向の要に:インターネットサービスの新基準(1/2 ページ) 昨今、Webサイトで扱う情報量は増大の一途をたどっている。2005年、ブログはもちろんコンテンツ管理の根底を支えてきたのは「データベース」システムにほかならない。どのような効果があり、どのような運用ノウハウがあるのだろうか? ショッピングサイト運営から、簡単なアンケートページに至るまで、Webアプリケーションでは、入力されたデータを保存する仕組みが必要だ。簡単なデータであればテキストファイルとして保存できるが、検索性を高めるためには、データベース利用が不可欠になる。 オンライン・ムック「インターネットサービスの新基準」では、サービス構築・運用・管理にかかわるユーザーを対象にノウハウを解説してきた。インターネットサービス開設のために、何が必要なのか? いまトレンドとなっているものは何か?
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する(なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい)。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物(ドキュメント)を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 (1)題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
2人の学者が、最近、ソフトウェアをオープンかつフリーに保つ一方で、開発者も利益を享受できるというビジネスモデルを提案する論文を書いた。このモデルでは、オープンソースソフトウェア会社が最新の開発成果の売上げと使用料から利益を得ながら、ある一定期間が経過したのちは、そのソフトウェアとソースコードを完全にフリーにする。 当該論文「Innovation Through Optimal Licensing in Free Markets and Free Software(自由市場とフリーソフトウェア:最適ライセンスによる技術革新)」は、マサチューセッツ工科大学(MIT)スローン経営大学院の博士課程に在籍するMarshall Van Alstyneと、ニューオーリンズのチュレーン大学で「情報と経営管理」を教えているGeoffrey Parker準教授の2人によって書かれたもので、フリー/オープンソフ
きっかけは知り合いのエンジニアから聞いた、何げないひと言でした。「納期? いざとなったら要件を変えちゃっても何とかするよ」。それがきっかけで300人のエンジニアに、「納期に間に合わないと分かったときに使う裏技術」を尋ねたわけです。 アンケート調査では、納期に間に合わせるためのワザ以外にも、前提となる納期の厳しさや現状の納期への考え方なども聞いています。 「仕事が始まった時点で納期達成が絶望的」(図1)ってかなりむちゃな話ですが、仕事の半分以上がそうだというエンジニアが4割もいます。普通の仕事だってスケジュールは徐々にズレていき、結局は納期と戦う羽目になるでしょ。それなのに、例えば「最初から納期は絶望的」な仕事が8割という人が、10人に1人いるわけです。 それを思うと、「何が何でも納期は守る」と答えた人のエンジニア魂が光りますね(図2)。しかもこの18%(53人)の「納期が絶望的な仕事」の割
あるAnonymous Coward曰く、"@ITの連載記事の中で[ 「悪魔に心を売っても納期を守る! 裏技術」という興味深い記事が掲載されている。 記事は、300人のエンジニアに「納期に間に合わないと分かったときに使う裏技術」という題でアンケートをとったもの。 IT業界だけに限定した記事ではないようだが、「仕事が始まった時点で納期達成が絶望的」な仕事の多さ、それに対する「テストの間引き」や「段階リリース」など、体験したことのある人も多いのではないかという話が、多々掲載されている。 かくいうタレコミ者も、覚えのあるものが存在している(--; 昨今、システム障害が大きな社会問題として取り上げられることが多いが、納期を延ばすのが難しい中で、どうすれば納期を守りつつ、問題を減らしていけるだろうか? 各位の経験した事例や、対策・裏技術などを語っていただきたい。 なお、話題が話題だけに、暴露話をAC
back はじめに このマニュアルは emacs (あるいは mule) を使いはじめてまだ間もない頃の 人のためのものです。emacs を一度も使ったことのない人は残念ながら 対象としていません (そういう人には emacs 付属のチュートリアルをすすめます)。 これを読んでも emacs が快適に使えるようになるかどうかはあなた次第です。 emacs はマウスやカーソルキーで操作することもできますが、 これらを使っているようでは上達しないということも 覚えておいてください。このマニュアルはよその人にも読めるように書いた つもりですが、基本的に csc (東工大 情報工学科 計算機室) で emacs を 使用する人を対象としています。そのため、日本語入力環境やメール環境については 必ずしもあなたのサイトとは一致しないかもしれませんので注意してください。 基本的なこと ファイル操作 カー
Webアプリケーションのユーザーインターフェイス[6] 「戻る」で入力データが消えてしまうフォームはいらない 「寛容性とユーザーコントロール」 ソシオメディア 上野 学 2005/12/22 前回「入力情報を預かる責任を果たせる画面デザインとは?」は、あらゆる経験則の土台となる価値観として、「ユーザーを尊重する」というユーザー中心の姿勢について述べました。今回からは、Webアプリケーションのユーザーインターフェイス(UI)・デザインを行ううえで有効な経験則を、少し具体的に考えていきたいと思います。 その前にまず、連載の第1回「ユーザーにとっては“ユーザーインターフェイス”こそが製品そのもの」で触れた HCI(Human-Computer Interaction)の分野でよく挙げられる、コンピュータを用いた対話型システムの設計原則を紹介しておきます。ここでいう「対話型システム」とは、ユーザー
内容説明 本書は、Red Hat Linuxを使用してインターネットサーバーを構築する方法を、見開き形式で簡潔にまとめた本である。サーバー構築の経験のない方のために、各サーバーの仕組みや基本的な設定項目など、サーバー構築にあたって知っておくべき基本知識を説明した。実際の設定操作については、極力Red Hat Linuxが提供するGUIのツールを用い、できるだけ簡単に設定できる方法を採った。 目次 第1章 インターネットサーバーの基礎知識 第2章 bindによるDNSサーバーの構築 第3章 Webサーバーの構築 第4章 Webサーバーの活用 第5章 ProxyサーバーSquid 第6章 sendmailによるSMTPサーバーの構築 第7章 POPサーバーの構築 第8章 IMAPサーバーの構築 第9章 FTPサーバーの構築 第10章 基本的なセキュリティ設定 著者等紹介 秋田克彦[アキタカツヒ
以前のブログで、テストをデザインの手段として捉える、TDD(Test Driven Development)の発展として、BDD(Behavior Driven Development)について紹介した。要は、テストにまつわるボキャブラリから、仕様周辺のボキャブラリに変更することから生まれる、新しい開発の捉え方だ。例えば、Stackが生成時に空であるという仕様を、こう表現する。 shouldBeEmpty() { Stack stack = new Stack(); Verify.that(stack.isEmpty); } 以前の、test, assert というボキャブラリではなく、should, verify というボキャブラリへの転向。 このBDDの本に関する、先行和訳の試みを、懸田さんが始めた!http://log.giantech.jp/BDDIntro-ja.html 要チェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く