サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC24
www.nulab.co.jp
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう ソースディレクトリの作成 依存ライブラ
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
■書籍 Subversion実践入門― 達人プログラマに学ぶバージョン管理(第2版) Mike Mason(著)、でびあんぐる(訳)、オーム社(刊) Subversionの基本的な使用法をはじめ、実プロジェクトでのバージョン管理の活用という観点で書かれていておすすめです。 パターンによるソフトウェア構成管理 Stephen P. Berczuk/Brad Appleton(著)、宗雅彦(訳)、翔泳社(刊) あんがい知らないうちにやっていることがパターンとして明記されています。Subversionの機能もこの書籍のパターンを実現しているものが多いです。本特集の構成管理に関する図はこの書籍の図を参考にしています。 達人プログラマー― ソフトウェア開発に不可欠な基礎知識 David Thomas、Andrew Hunt、Mike Clark(著)/テクノロジックアート(訳)/長瀬嘉秀(監訳)/ア
ソフトウェア構成管理(Software ConfigurationManagement、SCMとも呼ばれます)とは簡単にいうと、「ソフトウェアに対するすべての変更や修正を記録し、成果物をいつでも(場合によっては過去にさかのぼってでも)作成できるようにすること」です。本特集では、「バージョン管理」については「Subversion」を取り上げます。 ビルド ビルドとはソースコードをコンパイルして実行可能なファイルを作成することをいいます。基本的に依存するライブラリがないとビルドはできませんので、ライブラリの依存性管理もビルドの範囲に含まれてきます。「makeコマンド」や「antスクリプト」、そして本特集で扱う「Maven 2」は、ビルドを行うためのツールです。 リリース リリースソフトウェアをサーバに配置して利用者に対して公開したり、配布することをリリースといいます。リリース作業ではデグレード
dependencyの追加は、このscopeを意識して行うようにしましょう。依存ライブラリを追加したつもりでも 、間違ったscope設定を行うと、コンパイルできない、テストが実行できないなどの問題が起きますので 注意しましょう。 先ほどのServlet APIの例では、Webアプリケーション(WARファイル)には含めませんので、 scopeとして「provided」を指定します(注7)。 注4)http://mvnrepository.com/ 注5)http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html 注6)http://java.sun.com/products/javabeans/jaf/downloads/ 注7)これを指定しないと、サーブレットコンテナのServlet APIと WARファイルに含ま
デザインパターンは楽しいものです。 デザインパターンを理解すると、プログラミング、特に設計が楽しくなります。 柔軟性の高い設計で良いアプリケーションが書けるようになれば、技術者冥利に尽きると思いませんか? それでは、次章以降で具体的なパターンの解説に入っていきましょう。 本特集の内容はデザインパターンの入り口を叩くところまでです。 実際にデザインパターンをものにしていくには、読了後の実践と継続的な学習が必要になってくることでしょう。 コラムとして、デザインパターンの習得法、参考・推薦図書、推薦URLをご紹介します。 ■デザインパターン習得法 デザインパターンは諸刃の剣だといえます。正しく使うことで柔軟性の高いアプリケーションを作ることができます が、適用を誤ると複雑なだけで柔軟性の低いアプリケーションにもなりかねません。正しく使いこなすまでに、多くの 実践と失敗を繰り返すことになるでしょう
ここからは、作業コピーAと作業コピーBを題材に、Subversionのチーム開発に関連する操作を見ていきます。 まず準備として、通常の並行開発に見立てて、作業コピーBのほうにも変更を加えておきましょう。 作業コピーBのhoge.txt、hoge_conflict.txtを以下のように変更してください。 【hoge.txt】 a B C 【hoge_conflict.txt】 a B E 更新 先ほど作業コピーAでコミットした内容は、まだ作業コピーBには反映されていません。リポジトリの最新状態と同期を取るために「更新」(アップデート)と呼ばれる作業が必要になります。 更新を行う作業コピーのディレクトリ(C:\work\2\B)に移動し、svn updateコマンドでリポジトリと同期化を行います。 ●【更新】 svn update C:\ work\ 2\ B> svn update D ho
まずは、作業コピーAで次の変更を行ってみましょう。 ファイルの編集 ファイル(ディレクトリ)の追加 ファイル(ディレクトリ)の削除 ファイル(ディレクトリ)の移動 ファイル(ディレクトリ)のコピー 編集作業はいつも通りエディタを使用して行って問題ありません。その他のファイルに対する操作は Subversionの機能を使用して明示的に行う必要があります。 編集と状態の確認 hoge.txtとhoge_conflict.txtの編集を行ってみます。両ファイルとも、以下の内容に変更しました。 A b c ここで、作業コピーの状態を確認してみましょう。変更の確認を行いたいディレクトリ(C:\work\2\A) に移動し、svn statusコマンドで状態の確認を行います。statusコマンドを実行すると、チェックアウトや更新後にローカルで変更されたファイルの一覧が表示されます。ファイルが変更されて
SCMの中で、バージョン管理ツールは重要な位置を占めています。バージョン管理ツールの主な機能は、ソースファイルの変更の経過を管理する機能と、チーム開発用の機能です。 【ソースファイルの変更管理】 ソースファイルの変更を記録、保持し、そのファイルの変更を追跡できる!ソースファイルの状態を維持できる ソースファイルの変更を取り消したり、以前の状態に戻すことができる 【チーム開発】 同一ソースファイルに対して、複数の開発者が並行して変更を行える 同一ソースファイルに対して並行して行われた変更を統合する 同一ソースファイルに対して並行して行われた変更の競合を検出する 今回取り上げるSubversionは、上記の機能に加えて、次の利点も兼ね備えています。 コミットごとにリポジトリ全体でリビジョンを管理するため、ある瞬間の状態の取得が簡単に行える HTTP/HTTPSやSSHといった一般的なネットワー
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> Home | Top > 構成管理 実践入門 > 第4章 Maven2によるビルド入門 > なぜMaven2なのか? 第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージ
現在のソフトウェア開発では、バージョン管理ツールがほぼ当たり前のように使われています。ただ、このバージョン管理ツールに振り回されてプロジェクトが破綻してしまうことも見受けられます。 なぜ、このようなことが起こるのでしょうか? 筆者は、SCM(ソフトウェア構成管理)の説明が単なるバージョン管理ツールの使い方の説明で終わってしまっていることが原因だと考えています。 SCMをただのソースコードの履歴管理だけで終わらせてしまうのはもったいないことです。 SCMは、必要性は理解されているけれども、あまり深くまで追求されない作業です。第1章の参考文献で挙げた書籍『パターンによるソフトウェア管理構成』では、SCMを「配管作業」といっています。 本章では、『パターンによるソフトウェア管理構成』で取り上げられているパターンのいくつかを対話形式で紹介していきます。開発者がバージョン管理ツール使えるようになった
イントロダクション アプリケーションで扱うデータをモデル化してみると、オブジェクト同士の関係を単純な1対1の関係だけで管理できることはほとんどありません。 多くのオブジェクトは、他のいくつかのオブジェクトへの関わりを持つことで構造を作っています。 この構造が単純なうちはよいのですが、また別のオブジェクトへと次々に関わりを持っていくことで、構造はどんどん複雑になっていき、直感的に実装したり使ったりすることが難しくなります。 そんなときはコンポジットパターンが威力を発揮します。 コンポジットパターンは、要素であるオブジェクトと、複数の要素からなる複合オブジェクトを区別なく扱えるという特徴を持ちます。 この特徴を利用することで、構造を再帰的に組み立て、クライアントからの見た目をシンプルに保つことができます。 パターン解説 コンポジットパターンは、ディレクトリ構造のような再帰的な構造を解決すること
イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ
具体的な例 それではより具体的な例を見てみましょう。サンプルは商品の割引価格を計算するコードです。 割引価格には「会員の割引価格」「セール時の割引価格」「通常の割引価格」の3種類があります。 割引価格の種類を決定するのは、Mainクラス実行時のアプリケーション引数です。 Mainクラスは「java Main 価格 割引ロジック名(sale, member, 指定しないのいずれか)」の形式で実行します。 例えば「java Main 1000 member」で実行すると会員割引価格となり、「java Main 1000 sale」で実行するとセール時の割引価格となります。 「java Main 1000」と指定がない場合は、通常の割引価格になります。 各クラスの役割は次のようになります(図8~9)。 ◎DiscountLogic(リスト14) 割引計算のロジックのインタフェースです。各割引計算
次のページ
このページを最初にブックマークしてみませんか?
『株式会社ヌーラボ(Nulab Inc.)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く