eclipseのインストール(Eclipse 3.7 Indigo編) - 愚鈍人
Windows Vista , Business SR2に「Eclipse 3.7.0 Indigo Windows 32bit ベース / Pleiades All in One 3.7.0.v20110704 」をインストールしてみました。 インストール方法はEclipse3.6の時とまったく同じ。 Pleiades All in One 日本語ディストリビューションにはJavaのWeb開発に必要なツールやプラグインがあらかじめ含まれているので簡単に開発環境を構築する事ができます。 日本語化されている JREが含まれているので別途Javaをインストールする必要が無い tomcatのプラグイン等開発に必要なメジャーなプラグインが含まれている ダウンロード Pleiades (Eclipse プラグイン日本語化プラグイン)のURLを開く。 下図のように「Eclipse 3.7 Indigo
ソフトウェアテストの展望 (application/pdf オブジェクト)
© DebugEng Debug Engineering Institute DebugEng http://www.debugeng.com/ 2 © DebugEng Debug Engineering Institute 1. 2. 3. 4. 5. 6. © DebugEng Debug Engineering Institute 1 � 4 © DebugEng Debug Engineering Institute � 5 © DebugEng Debug Engineering Institute �SW 6 © DebugEng Debug Engineering Institute � � 1. 2. 3. © DebugEng Debug Engineering Institute 2 � 8 © DebugEng Debug Engineering Institute
第10回 開発プロセスの上手な組み合わせ
今回は、前回「第9回 UMLベース開発プロセスの流れ」説明した開発フェイズの基本知識を基に、いくつかの開発フェイズを組み合わせながら開発を進める方法（開発プロセス）について説明をしていきます。UMLの使い方について例題を使って説明する予定でしたが、プロセス関連でお話ししたいことが山ほどあり、今回は例題まで話をつなげることができません。よって、例題については次回に回します。皆さん気長にお付き合いください（笑）。 開発フェイズとUMLモデリング 前回説明したように、オブジェクト指向型開発プロセスでは、表のような開発フェイズを持っています。実際、これらの開発フェイズの名前や、その中で行う作業の定義については、開発プロセスの中で定義されているのですが、どの開発プロセスを利用するにしても、下記のフェイズを理解して開発を進めることが重要です。これは、前回の順平君の体験例にてお分かりいただいたと思います
障害記録票と問合せ管理簿の2重管理問題 - プログラマの思索
応用情報技術者試験で、インシデント管理をExcelの障害記録票と障害管理簿で2重管理していた問題が出ていた。 この手の不手際がよくありそうなのでメモ。 以下ラフなメモ書き。 【元ネタ】 平成22年度春期試験 応用情報技術者試験（AP）午後問題 平成22年度春期試験 応用情報技術者試験（AP）午後問題解答 上記の問11にITILのサービスサポートのインシデント管理の問題がある。 問題の詳細は省略。 その事件として、まずかった点は二つある。 問合せ管理簿で、他の問合せの最新状況が反映されていなかったために、過去直近の問合せと原因は同じと判断を誤ったこと。 もう一つは、問合せ管理簿に、プログラム改修の要否や改修予定日などが書かれていなかったために、ユーザに正しい情報を即答できなかったこと。 ITの運用保守業務では、インシデント管理ではまず障害の暫定措置や早期復旧を最優先にして、根本原因の解決は
設計書を作ってるせいで生産性落ちてないか？
1 ：仕様書無しさん：2007/01/25(木) 23:27:12 概要設計書、外部設計書、詳細設計書 クラス図、シーケンス図、状態遷移図、アクティビティ図 リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・ アホか、、 外設した後はさっさとコーディングした方が 設計書なんかで妄想してるより何倍も多くのことが分かるっての。 で、実装とテストが終わったあとに 改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。 だいたい「ソフトウェア 設計書」でググったら 現状懐疑論ばっかじゃねーか。 2 ：仕様書無しさん：2007/01/25(木) 23:31:57 設計書よりも デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？ 3 ：仕様書無しさん：2007/01/25(木) 23:37:05 >>2 そういう単純作業は派遣社員に
実装をしない設計者は要らない。 - 雑文の日々
よく大企業のシステム開発では実装をしない（できない）設計者がいる。 彼らの仕事は仕様書を書くことだ。客と打ち合わせをして仕様書にまとめる。 そしてあとはプログラマにそれを元に作らせるという塩梅である。 彼らは以下の理由から要らない。 １．実装上のコストを計算できないのに仕様を決める ２．設計を実装に落とす段階の苦労をしないので自分の仕事に責任を取らない ３．単に工程上の上流に位置しているからという理由で技術があると思われている。 ４．単に工程上の上流に位置しているからという理由で実装をする技術者よりも報酬が高い 要はプログラマが設計者を兼ねればいいだけの話である。 これはウォーターフォールモデルの問題でもある。 よくウォーターフォールモデルは駄目だという主張があるが、しかしこのモデルには２種類のやり方がある。縦割り方式か横割り方式かという違いだ。この違いは大きい。 縦割りは機能ごとに設計・
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
ソフトウェアテストのプラクティス — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
alternative dvamp project 技術の空洞化
自称Javaが出来る人でも設計書をまともに書けない。先週は社内の諸事情からプログラミングをする機会を得た。 既にプロパーによってプログラム設計書は記載済で、製造工程以後を担当というもの。 早速プログラム設計書を見てみると…。会員No登録チェックメソッド(引数int型で会員番号)：戻り値はなしtry-catch宣言をする。try-catch宣言をする。try-catch宣言をする。Connection conn = new Connection();PreparedStatement pstm = new PreparedStatement();ResultSet rs = new ResultSet();DBに接続する。pstm = conn.prepareStatement(strSQL);pstm.setString(1, 会員番号);pstm.executeUpdate();conn
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
DAOとかVOとかDTOとか - 人類みんなごくつぶし
設計、コーディングで用いられる言葉の整理。こいつらって何よ？ DAO(データアクセスオブジェクト) VO(バリューオブジェクト、値オブジェクト) DTO(データトランスファーオブジェクト) エンティティ これらは、EJBの出現により(？)メジャーになった言葉たちです。 DAOは、DB(永続ストア)にアクセスするためのクラスです。 たいてい、VOを引数に受け取って、INSERT、UPDATEを行ったり、 SELECTしてVOやVOのリストを返したりします。 DTOはVOとほぼ同義ですが、微妙に違います。 何が微妙に違うかはメンドクサイので忘れます。 エンティティは、DAO+VO(DTO)のようなペアでDB操作を行わず、 エンティティクラス自体のメソッドにINSERTやSELECTを行うメソッドを定義します。 (SELECTは別のクラスにしたり、staticメソッドにしたりもする) VO/DT
入門Mercurialの感想 - プログラマの思索
Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。 【元ネタ】 Mercurial の利用 特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) ダウンロード - TortoiseHg - SourceForge.JP 「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。 平易に書かれていてとても読みやすい。 また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。 エピローグに「あ！構成管理って楽しいんだ？！」という節がある。 Mer
HTML5が注目を浴びる理由とは？ ここが違う！サンプルで見るHTML5（1）
はじめに この連載では、「HTML5」をとりあげ、全6回に分けて、これまでの技術とどのような違いがあるのか、具体的にサンプルのコードを示しながら解説していきます。 HTML5はなぜ注目されているのか HTML5は、今やウェブ業界の流行語といっても良いほどの過熱ぶりです。HTML5は、名前の通り、HTML4の後継に当たる仕様です。とはいえ、HTML5に注目しているのは、ホームページを作成するウェブ制作者だけではありません。ウェブ業界に限らず、あらゆるIT関連業界で注目を浴びています。なぜ、これほどまでにHTML5が注目を浴びているのでしょうか。 この理由は、大きく分けて2つあります。1つはマークアップです。もう1つはAPIです。 マークアップの仕様を更新 まずは、マークアップの視点から見ていきましょう。これは、とりわけウェブ制作者、中でもウェブページ製作の現場において重要です。これまでウェブ
アーキテクト向けのパターン本 - 達人プログラマーを目指して
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 作者: F.ブッシュマン,H.ローネルト,M.スタル,R.ムニエ,P.ゾンメルラード,Frank Buschmann,Hans Rohnert,Michael Stal,Regine Meunier,Peter Sommerlad,金沢典子,桜井麻里,千葉寛之,水野貴之,関富登志出版社/メーカー: 近代科学社発売日: 2000/12メディア: 単行本購入: 15人 クリック: 448回この商品を含むブログ (54件) を見るPattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series) 作者: Frank Buschmann,Regine Meunier,Hans Rohnert,Peter Somme
アーキテクトもプログラミングするべきか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して で以下のようなコメントをいただきました。 アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな アーキテクトの働き方の参考に。 そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。 アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの 現代的アーキテクトの仕事 このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をす
業務システムでオブジェクト指向は必要か？ - 達人プログラマーを目指して
半年前に爆発的に盛り上がったネタで今更ですが、 実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ について。多態性（ポリモーフィズム）やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論（多くは反論）が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、（炎上した多数のコメントも含めて）非常に貴
ソフトウェアテスト技法ドリルの感想 - プログラマの思索
秋山さんが執筆された「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」を読んでみた。 テストケース作成技法がとても実践的で、しかもフリーのツールを色々説明していて役立ちそうな感触を持った。 感想をメモ。 【元ネタ1】 【感想】ソフトウェアテスト技法ドリル／秋山浩一 - Software Quality Topics. ソフトウェアテストの勉強室: ソフトウェアテスト 本棚３ 「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」は、テストケース作成技法を初心者～中級者レベルに向けて書かれていると思われる。 同値分析、境界値分析の使い方から原因結果グラフ、HAYST法、ペアワイズ法など各種の技法が説明されている。 僕が興味を惹いたのは、原因結果グラフからデシジョンテーブルを生成するツールCEGTestと、ペアワイズ法によって組み合わせを生成するツールPictMasterの説明がと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 問題プロジェクトの火消し術: 長尾清一: 本
JUnitメモ(Hishidama's JUnit Memo)
Amazon.co.jp: 現場で使えるソフトウェアテスト Java編: 町田欣史: 本
