jenkinsインストール手順

Posted on by

Windows 64bit環境、pleiadesバンドルのtomcat上でjenkinsを動作させる手順。

http://mirrors.jenkins-ci.org/war/latest/jenkins.war

からjenkins.warをダウンロード。

pleiades/tomcat/6.0/webapps配下に、jenkins.warをコピー。（パスは自分の環境に合わせること）

tomcat起動で、勝手に配備される。

http://localhost:8080/jenkins

にアクセスすれば使える。

で、Jenkinsの管理画面で、文字コード設定されていないよって警告でるので、下記対応を入れる。

pleiades/tomcat/6.0/conf/server.xmlを編集。


<Connector port="8080" protocol="HTTP/1.1"
           URIEncoding="UTF-8"  ←追加

保存後、tomcat再起動で警告が消える。

Popularity: 3% [?]

yumのproxy設定

Posted on by 

# echo "proxy=http://hogeproxy.com:8080" >> /etc/yum.conf

これで、proxy配下でもyumが使えるようになる。
システムプロキシを設定していても使ってくれないので注意。

Popularity: 1% [?]

CMakeインストール

Posted on by

ビルド＆インストール


$ tar zxvf  cmake-2.8.7.tar.gz
$ cd cmake-2.8.7
$ ./bootstrap --prefix=/usr/local/cmake-2.8.7
$ make -j4
# make install
# cd /usr/local
# ln -s cmake-2.8.7 cmake

パス追加


# vi /etc/profile

PATH=/usr/local/cmake/bin:$PATH  ←追加
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC

反映


$ source /etc/profile

Popularity: 3% [?]

CentOS5.7 x86_64　yumでMySQL5.5へアップグレード

Posted on by

■リポジトリ追加


# rpm -ivh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
# rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

■更新


# yum update

■データベースバックアップ
もしものときのためにバックアップ。アップグレードに成功したら使わない。


# mysqldump  -u root -p --all-database > all.dump

■アップグレード


# /etc/init.d/mysqld stop
# yum remove mysql mysql-server mysql-devel
# yum install --enablerepo=remi perl-DBD-MySQL
# yum install --disablerepo=base --enablerepo=remi mysql mysql-server mysql-devel
# /etc/init.d/mysqld start
# mysql_upgrade -uroot -p

/etc/my.cnfにcharsetの値を設定

# /etc/init.d/mysqld restart
# chkconfig mysqld on

Popularity: 4% [?]

CentOS5.7 x86_64にyumでgitインストール

Posted on by

■rpmforgeの設定
http://pkgs.repoforge.org/rpmforge-release/ にアクセスし、最新版のファイルを確認。


$ wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
# rpm -Uvh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

■初期設定が常時使用となっているので、都度使用へ変更


# sed -i 's/enabled = 1/enabled = 0/g' /etc/yum.repos.d/rpmforge.repo

■gitインストール


# yum --enablerepo=rpmforge install git

Popularity: 3% [?]

Chain of Responsibilityパターン

Posted on by

■目的
ある要求が発生したときに、その要求を処理するオブジェクトをダイレクトに決められない場合に、たらい回しを実現するためのパターン。

■メリット

  • 要求を送信するオブジェクトと受信するオブジェクトの関係が弱まる
  • 要求を処理するオブジェクトをクライアント側に意識させずに自動的に割り当てることができる
  • 要求の処理方法を動的に変更できる

■考慮事項

  • 要求を処理する順序や条件を考慮する必要がある
  • チェーンが循環しないように注意する必要がある
  • たらい回すことで、ダイレクトに処理オブジェクトを決定する方法より処理が遅くなる

■関連しているパターン

  • Compositeパターン
  • Commandパターン

Popularity: 2% [?]

Visitorパターン

Posted on by

■目的
処理をデータ構造から分離するために適用する。
Visitorがデータに訪問して処理を行う。

■メリット

  • データ構造クラスを変更しなくてもConcreteVisitorを追加するだけで機能を追加できる
  • 具象クラスごとに異なる操作を提供する
  • １つのクラスに１つの操作をまとめることができる。
    具体的にはVisitorクラス側に操作をまとめられる。

■考慮事項

  • ConcreteVisitor役の追加は容易
  • ConcreteElement役の追加は困難
    すべてのVisitorクラスに修正が必要になるため。
    ConcreteElementの追加が想定されるケースではパターンを適用しない方がよい。
  • ConcreteVisitorの数が少数である場合は、不必要に構造が複雑になるので適用を控えた方がよい。

■関連しているパターン

  • Iteratorパターン
    関連しているというよりは、ObjectStructureの実現に必要。
  • Compositeパターン
  • Interpreterパターン

Popularity: 2% [?]

Decoratorパターン

Posted on by

■目的
機能を組み合わせて新たな機能を作成する場合や、機能を実行時に付け外したい場合に役に立つパターン。
代表的な実装例として、java.ioパッケージの各種APIが挙げられる。

■メリット

  • オブジェクトに動的に機能を追加できる
  • 機能の組み合わせが容易である

■考慮事項

  • Componentで定義するメソッドを必要最小限にした方がよい。Componentが複雑になると、柔軟性が失われる可能性がある。
  • Decoratorパターンを使うと、よく似ている小さなクラスがたくさん作られてしまうという欠点もある。

■関連しているパターン

  • Adapterパターン
  • Strategyパターン

Popularity: 2% [?]

今年の目標

Posted on by

■必達目標

  • 今やっているプロジェクトを軌道に乗せる
  • データベーススペシャリスト取得
  • スクラムの社外イベントに参加。認定スクラムマスターの取得。
  • 英検４級取得

■追加目標

  • Webコンポーネントディベロッパー取得
  • ネットワークスペシャリスト取得
  • 英検３級取得

英語の目標がかなり弱気ｗ
ま、優先度的にはこの辺からはじめるのがよかろう。

Popularity: 2% [?]

Compositeパターン

Posted on by

■目的
ディレクトリとサブディレクトリ、ファイルの関係のように、容器と中身を同一視し、再帰的な構造を作るパターン。
ツリー構造の実現に最適。

■メリット

  • 集団を構成するクラスと要素を構成するクラスを一様に扱え、クラスの数を減らすことができる。
  • ツリー構造全体を同じ方法で扱うことができる。
  • 新しいグルーピング単位を容易に追加できる。
  • 新しいコンポーネントを容易に追加できる。

■考慮事項

  • 循環参照に注意する必要がある。
  • 過度に適用しすぎると、論理的に正しくない構造を作り出してしまう恐れがある。たとえば、ツリー構造に親子関係があるのに、子の下に親を追加できたりしてしまうなど。

■関連しているパターン

  • Commandパターン
    「マクロコマンド」を作るときに、Compositeパターンが使われる。
  • Visitorパターン
  • Decoratorパターン

Popularity: 2% [?]

Strategyパターン

Posted on by

■目的
アルゴリズムを容易に切り替えるためのパターン

■メリット
・アルゴリズムを容易に切り替えることができるようになる
・動的にアルゴリズムを切り替えることもできる

■考慮事項
・クラス数が増える。柔軟性を増していることにもなるが、単純すぎる構造の場合はパターンを適用しなくてもいい場合がある。

■関連するパターン

  • Flyweightパターン
    ConcreteStrategy役は、Flyweightパターンを使って複数個所から共有できる場合がある。
  • Stateパターン
    ともに委譲先を切り替えるパターンで構造がよく似ているが、目的が異なっている。

Popularity: 2% [?]

Bridgeパターン

Posted on by

■目的
「機能のクラス階層」と「実装のクラス階層」を分離するために使う。

■メリット
・階層を分離しておくことで、拡張する際にクラスの見通しがよくなる。
・委譲を用いることで、クラス間の結びつきが緩くなり、ソースコードの変更点も少なくて済む。
・クラスの数を減らすことができる。

■考慮事項
・開発が進んでからパターンを適用しようとすると、変更点が大きすぎて困難なケースが多い。

 

Popularity: 2% [?]

AbstractFactoryパターン

Posted on by

■目的
Builderパターンと同様に、複雑なインスタンスの生成に役立つパターン。
Builderパターンが初期化処理をメソッドで分割していたのに対し、AbstractFactoryパターンは、抽象的な部品を組み合わせることで、 インスタンスを生成する。

■メリット

  • クライアントから具体的なクラスを隠蔽できる
  • 一緒に使用すべき部品の生成処理をひとまとめにすることができる。

■考慮事項

  • 新たなFactoryを追加することは容易だが、新たな部品を追加することは困難（既存のすべてのFactoryに手を入れなければいけないため）。
    よって、インスタンス生成に必要な部品の数が変化する可能性が高い場合は適用を控えた方がよい。

Popularity: 2% [?]

Builderパターン

Posted on by

複雑なインスタンス生成処理を簡略化するためのパターン。

複雑な初期化を経てインスタンスを生成する場合や、コンストラクタが数多くのパラメーターを要求する場合、Builderパターンを導入することで、インスタンス生成の複雑性を緩和することができる。
インスタンスの初期化ロジックを独立させることができるので、検証処理を細かく行うことができるというメリットもある。

Builderパターン単独で使うと、Directorに対するconstructメソッド呼び出しを忘れそうな気がするので、他のパターンと組み合わせて、ConcreteBuilderの生成とDirectorによる初期化を隠蔽して、インスタンスを返す形にするとなお良しな気がする。

Popularity: 2% [?]

Prototypeパターン

Posted on by

newでインスタンスを生成するのではなく、cloneで登録済みのインスタンスから新しいインスタンスを複製するパターン。

FactoryMethodパターンと比べ、インスタンス生成用のクラス（Client）がひとつで済むというメリットがある。
逆にデメリットとして、ディープコピーが必要な場合、cloneメソッドを注意してオーバーライドする必要が出てくる。
生成するインスタンスのコンストラクタが呼び出されないという点にも注意しておかないと想定外の挙動を招く。

基本的にはFactoryMethodの方が優れているケースが多いが、以下の条件のいずれかに当てはまる場合は導入を検討してもよい。

  1. 生成するインスタンスの種類が多すぎて、Factory（ConcreteCreator）を大量に作りたくないケース。
  2. インスタンスの生成が複雑な過程を経るもので、クラスからの生成が難しい場合。
  3. フレームワークと生成するインスタンスを分けたい場合。

癖はあるが、適切な場所で使うと強力なパターン。

Popularity: 2% [?]

Singletonパターン

Posted on by

インスタンスがひとつであることを保証するパターン。
システム環境変数とかに使う。

デザインパターンに詳しくない人でも、これだけは知っているケースが多い一番有名なパターン。
そして乱用は禁物。
なぜならグローバル変数と実質的に変わらないから。

スレッドセーフを意識して作らないと意図しない挙動を引き起こすので注意。
つまり、並行性をあげたい場合ボトルネックになる。
これも乱用禁止の理由のひとつ。

Popularity: 2% [?]

FactoryMethodパターン

Posted on by

TemplateMethodをインスタンスの生成に応用したパターン。
インスタンス生成の枠組みと、実際のインスタンス生成のクラスを分離することでクラス間の依存関係を弱めることができる。

もっと言うと、newによる実際のインスタンス生成を、インスタンス生成のためのメソッド呼び出しに代えることで、具体的なクラス名による束縛からスーパークラスを解放する。

framework側のCreatorクラスでcreateというテンプレートメソッドを用意する。

CreatorもしくはConcreteCreatorは、Singletonパターンを適用することが多い。

Popularity: 2% [?]

TemplateMethodパターン

Posted on by

抽象クラスで、処理の流れを記述して、詳細はサブクラスにおまかせするというパターン。

処理の流れを記述する抽象クラスのメソッドをテンプレートメソッドといい、finalにしてオーバーライドを防止するのが流儀。

割と無意識に使っているであろうパターン。
逆にこれがわかってないようだと、オブジェクト指向の旨味をほとんど理解していないと思われる。

Popularity: 2% [?]

Adapterパターン

Posted on by

作成済みのAdapteeクラスを、Clientが期待しているインタフェースTargetから利用できるように、変換するクラスがAdapterクラス。

Adapteeを継承して、is-a関係として実装するやり方と、Adapteeに委譲する、has-a関係として実装するやり方がある。

委譲パターンの場合、Targetを抽象クラスとすると説明にはあるのだが、インタフェースでも問題ないような気がする。
抽象クラスじゃないとダメな理由あるんかな？

どんな場合に使うかというと、サードパーティーが提供するクラスを自分達が使いやすいAPIに変換するときとかに使う。
Wrapperとも呼ぶ。

Popularity: 2% [?]