システムを構築するに当たっては、従来、ERに代表されるデータモデリング手法とUMLに代表されるオブジェクト指向分析設計手法を使い分けることが多い。しかし、こうしたアプローチにも課題が出てきた。UMLとデータモデルを別々に設計することで情報が重複し、混乱を起こしやすくなるという問題だ。 本ホワイトペーパーでは、業務フローとユースケースでシステム化すべき対象を明確にし、そこからUMLとデータモデルを連携させて設計する方法を解説する。さらに、機能とデータの関係をCRUDを用いて検証するという、実際のシステム開発の流れに沿ったシステム設計手法についても紹介。システム構築から保守までをムダなく漏れなく行うために、フローチャートやクラス図といったオブジェクト指向の要素とデータモデルを連携させたシステム設計のポイントを示す。
ソフトウエアの改造がトラブルの温床になっている。改造案件が増える一方で,改造ならではの方法論が未熟だからだ。プログラマやSE,プロジェクト・マネージャが一丸となって「改造力」を高めるノウハウを解説する。 第1回 ソフトウエア改造力が足りない:変更ミスがトラブルの温床に 第2回 ソフトウエア改造力が足りない:工数膨らませる影響調査と確認テスト 第3回 対応すべき案件を選ぶ:要望を集め,工数を概算する 第4回 対応すべき案件を選ぶ:費用対効果で優先順位を判断する 第5回 改造の影響を調べる:詳細な工数とソースコードの変更箇所を洗い出す 第6回 改造の影響を調べる:ドキュメントをまとめ作業計画をレビューする 第7回 テスト範囲を最適に決める:過去のテスト項目集めて漏れを減らす 第8回 テスト範囲を最適に決める:シナリオや環境整備でテストを効率化する 第9回 テスト範囲を最適に決める:本番リリース
昨今、良くある(僕自身も好みの)組み合わせで、 ・IDE・・・Eclipse ・ビルドツール・・・Maven2 及び Eclipse m2eclipseプラグイン ・コンテナ・・・Tomcat 及び Tomcatプラグイン ・フレームワーク・・・Seasar2 及び S2ファミリー と言うのがあります。 しかし、開発環境構築は結構難問です。 Eclipse、Maven2、m2eclipse、Tomcatプラグイン... それぞれ「個別の問題」にフォーカスしたツールを組み合わせようとすると、 細かいところでギャップがあって、各ツールの長所を活かしつつ、うまく連携させるには試行錯誤が必要です。 そこで、以下のような各ツールの長所を活かせる開発環境を作ってみる。 1.Eclipse ・修正したソースのインクリメンタルコンパイル。 ・その他もろもろ... 2.Maven2 ・pom.xmlによるプ
平素よりイベントカレンダー+ログをご利用いただき、誠にありがとうございます。 イベントカレンダー+ログは「IT・製造業・ビジネス関係のイベント(セミナー・展示会・勉強会・コンテスト・Webイベントなど)を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー+ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年6月30日(火)15:00をもちましてイベントカレンダー+ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。本連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する(編集部) OpenIDってなんだろう? 現在、国内外でにわかに注目されつつあるOpenIDという仕組みを聞いたことがあるでしょうか? これはユーザー中心の分散ID認証システムですが、まだ日本での普及は進んでいない状況です。 これにはいくつか原因が挙げられるでしょうが、筆者はOpenIDが正しく理解されていないことが原因だと考えます。 本連載ではOpenIDの現行仕様、およびその拡張仕様とともに、実装を例に取りつつOpenIDとは何かということを明らかにしていきます。最終的にはOpenIDが切り開く未来を見るため、現在策定中の次期仕様についても触れていきたいと思います。 広がりつつあるブラウザベ
今年のオブジェクト倶楽部の秋イベントは、永和システムマネジメントの社員教育を外部に公開する、というユニークな形態で行われました。参加数100名のうち、50名が社員、50名が外部、という構成です。そして、その後の懇親会も、全体50名参加で、25名が社員、25名が外部。大家族宴会と、町内会が一緒になったようなおもしろい会でした。 目的は、案外、社内に私のプレゼンを聞いたことがない人が多いので、ここで一回聞いてもらおう、ということと、社内と社外のマッシュアップもおもしろかろう、という主旨。 私は、今回、この「プロジェクトファシリテーション」の講演が80回目になります。やる度にちょっとずつ修正しているのですが、これだけの長寿セミナーになってうれしく思います。 当日のタイムテーブルは、 「プロジェクト・ファシリテーション」の講演 二人一組で、「過去の最高のチーム」について、話し合う 懇親会(希望者)
昨日Cubbyのリリース作業をやったので、備忘録の意味も込めて手順を晒してみます。間違いやもっといい方法あればつっこみ歓迎です。 まず、trunkからリリース作業をおこなうためのリリースブランチを作成します。ブランチのコピー中に他のコミッタがコミットすると問題あるので手始めにtrunkのリビジョンを確認しておきます。 svn info https://www.seasar.org/svn/sandbox/cubby/trunk 最終更新リビジョン: 100 次にtrunkをリリースブランチにコピーします。 svn cp https://www.seasar.org/svn/sandbox/cubby/trunk https://www.seasar.org/svn/sandbox/cubby/branches/0.9.1.x -m 'release branche 0.9.1.x' 再度、
ニコニコ動画:https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人(わだ たくと)といいます。 このたびgihyo.jpにて、テスト駆動開発(TDD)の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演! テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演! リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演! テスト駆動開発」と「実演! リファクタリング」は、本誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方
本連載においても、上記の5つの機能に関して比較を行っていきます。今回は1つ目の機能である「情報収集機能」について比較を行ないます。 情報収集機能の比較 情報収集機能については、監視対象の状態を収集する機能に加え、情報収集の設定や収集したデータの保存形式を対象として比較を行ないました。各比較項目の説明を以下に示します。 情報収集機能 リソース監視:専用エージェントを用いたCPU/メモリ/ディスク/ネットワークなどの内部リソース監視が可能かどうか ネットワーク監視:ping監視、ポート監視などのネットワーク越しの状態監視が可能かどうか SNMP監視:SNMPを利用したポーリング/トラップ監視を行なえるかどうか 情報収集設定 設定方法:情報収集の設定変更を行なう方法/ツール 保存形式:情報収集の設定が保存される形式 設定変更後の再起動:情報収集の設定を行なった後にサービスを再起動する必要があるか
新しいソフトウェア構成管理(SCM: Software Configuration Management)ツールを自社内に展開するとき、実装担当者は、しばしば詳細な活動まで完璧に行おうとする一方、これまでのまずい大規模なやり方 を、知らず知らずに推し進めてしまいます。その結果として、大きな失敗を招いてしまいます。 ここでは、SCM展開における著者の経験に照らした、高度なSCM実践方法(ベストプラクティス)をご紹介します。 「道具は、それを使う人によって効果が変わる」とよく言われます。我々は、ソフトウェア構成管理(SCM)ツールの提供者、あるいはソフトウェア会社に対 するコンサルタントとして、SCMのベストプラクティスについての適切なアドバイスをしばしば求められます。すなわち、「どのようにSCMソフトウェアを 展開すれば最大の利益を得られるか」という内容のアドバイスです。このような要請に対し
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
今月で今やってる仕事の契約が切れるので,ここで培ったノウハウなどをメモしておこうと思う。 しかし,今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。 プロジェクトポータルまわり とりあえず,Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この3セットがないプロジェクトなんてうんこ。 とにかくTrac-Subversionの連携が強力なので,Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉(数あるプラグインを有効利用しよう)。 marsのメモ - Trac marsのメモ - MacroBazaar - The Trac Project marsのメモ - 角谷HTML化計画(2006-04-25) marsのメモ - trac-post-commit-hookが
一般公開サイトを作るときには、各種のブラウザで正しく表示されるかを確認する必要があるが、 OSの種類 × ブラウザの種類 × バージョン をテストするとなると、かなりの数の環境が必要になってしまう。 VirtualPCやVMwareなどの仮想化ソフトで環境を作ったとしてもHostPCのメモリ容量などもあるので、 結構大変だ。 そこで、このサイト http://browsershots.org/ http://gigazine.net/index.php?/news/comments/20060908_browsershots/ を使うと、 Linux Windows Mac で FireFox Opera Konqueror IE Safari で対象サイトのスクリーンショットを作成してくれるので、結構便利。 しかし、リリース前のサイトをテストするのには使えないので、ローカルの環境にインス
テストと言うフェーズはシステム開発における重要な要素であるにも関わらずおざなりにされがちだ。ここがうまくいかないために立ち行かなくなる、または炎上するプロジェクトが多いにも関わらずだ。 テストを徹底する体制を整えよう。プロジェクト管理にソフトウェアを導入するのと同様にそのためのシステムを導入しよう。 今回紹介するオープンソース・ソフトウェアはTestLink、Webベースのテスト管理ソフトウェアだ。 TestLinkはテストを管理するためのソフトウェアで、テストケースの登録、管理、評価実行とその結果集計を行う事ができる。テストケースを仕様書として出力することも可能だ。 また、要求定義を登録してテストケースと関連付けることや、MantisやBugzillaといったBTS(バグトラッキングシステム)と連携させることもできる。 さらにTestLink日本語化プロジェクトを通じてTestLinkを
今、入力している会員登録のテスト、自動的に操作できればどれ程システムテストが楽になるだろうか。エラーが起きるたびに入力をやり直していたら、気持ちまでめげてしまう。 システムでは同じ操作、繰り返しの操作はCronやスクリプトで自動実行するようにする。ブラウザであってもそれは同じだ。 今回紹介するフリーウェアはCoScripter、ブラウザを自動操作するFirefoxアドオンだ。 CoScripterはFirefoxアドオンとしてインストールするソフトウェアで、簡単に呼び出して利用できる。Webサイトと連携し、自動操作スクリプトは共有し、利用できる(プライベートにしておくこともできる)。 特徴的なのは操作の記録がWikiベースで行われる点だ。JavaScriptのようなプログラム的な書き方ではなく、箇条書きで書いていくだけで良い。録画(?)機能もあるので、まず最初に操作してその結果を修正すれば
シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー
設計・実装から運用,メソドロジまで,最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」(アンチパターン)があるだろう。だが,その理由を問われると,うまく説明できないことがあるのではないだろうか。突き詰めて考えると,状況によっては「やっても構わない」こともあるし,技術の進化に伴い「やれるようになってきた」こともある。そこで設計,実装,テスト,運用,メソドロジの各分野について,取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル3~レベル1の3段階あり,レベルの数字が大きいほど,やってはいけない度合いも大きい。 関連サイト: ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く