判断と処理を分けて読みやすくする

判断と処理を分けると、読みやすく、テストしやすく、デバッグしやすくなります。

例は javascriptで書いています。

1.初期バージョン

最初に書くバージョンはだいたいこんな感じです。
「もろもろの処理」は、複数行だったり、if文やfor文を含むことがあります。

function func2 (a, b) {
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                もろもろの処理_1
            } else {
                もろもろの処理_2
            }
        } else {
            もろもろの処理_3
        }
    } else {
        もろもろの処理_4
    }
}

2.もろもろの処理をそれぞれ別メソッドにします。

function func2 (a, b) {
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                func2_1();
            } else {
                func2_2();
            }
        } else {
            func2_3();
        }
    } else {
        func2_4();
    }
}

function func2_1() {
    もろもろの処理_1
}

function func2_2() {
    もろもろの処理_2
}

function func2_3() {
    もろもろの処理_3
}

function func2_4() {
    もろもろの処理_4
}

3.「判断」と「処理」を別メソッドにします。

function func2 (a, b) {
    var num = case_number(a, b);
    process(num);
}

function case_number(a, b) {
    var num = 0;
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                num = 1;
            } else {
                num = 2;
            }
        } else {
            num = 3;
        }
    } else {
        num = 4;
    }
    return num;
}

function process(num) {
    switch (num) {
        case 1:
            func2_1();
            break;
        case 2:
            func2_2();
            break;
        case 3:
            func2_3();
            break;
        case 4:
        default:
            func2_4();
            break;
    }
}

4.判断内のif文のネストをelse〜ifで小さくします。

function case_number(a, b) {
    var num = 0;

    if (a <= 10) {
        num = 4;
    } else if (a <= 20) {
        num = 3;
    } else if (a <= 30) {
        num = 2;
    } else {
        num = 1;
    }

    return num;
}

5.デシジョンテーブル風のコメントをつけておきます。

/*
| # | a     | action  |
| - | ----- | ------- |
| 4 | <= 10 | func2_1 |
| 3 | <= 20 | func2_2 |
| 2 | <= 30 | func2_3 |
| 1 | > 30  | func2_4 |
*/
function func2 (a, b) {
   ...
}

6. if文の条件式が長いときは、それぞれ別メソッドにします。

function case_number(a, b) {
    var num = 0;

    if (is_later_equal(a, 10)) {
        num = 4;
    } else if (is_later_equal(a, 20)) {
        num = 3;
    } else if (is_later_equal(a, 30)) {
        num = 2;
    } else {
        num = 1;
    }

    return num;
}

function is_later_equal(a, x) {
    var f = (a <= x);
    return f;
}

最後に、func2メソッドの処理をとりだして、別クラスにします。

cordovaで開発したiPhoneアプリをappiumでテスト(2/2)

cordovaで開発したiPhoneアプリをAppiumでテストしたので、まとめました。

cordovaで開発したiPhoneアプリをappiumでテスト(1/2)
1.目標
2.simulator用appをビルド
3.appium他のインストール
4.Appiumデスクトップのインストール
5.Appiumデクトップを起動、Inspectorウィンドウで操作の記録

cordovaで開発したiPhoneアプリをappiumでテスト(2/2)
6.nodeでテストケース作成(アプリ起動のみ)
7.テストケースの実行
8.テストケース作成(座標をタップ、スクリーンショット保存)

6.nodeでテストケース作成

githubにappium公式サンプルソースがあります。
https://github.com/appium/sample-code

sample-code/examples/node/helpers/*.js
sample-code/examples/node/ios-simple.js
sample-code/examples/node/package.json
をダウンロードして、ios-simple.jsを改造します。

/Users/taro/projects/hello/platforms/ios/appium-testcaseの下に
helpers/*.js
ios-simple.js
package.json
を保存しました。

必要なnodeモジュールをインストールします。

$ cd /Users/taro/projects/hello/platforms/ios/appium-testcase
$ npm install

beforeメソッドのdesired変数は、「4.Appiumデクトップを起動、Inspectorウィンドウで操作の記録」のdesired capbilitiesの各項目を参考に設定してください。

テストケースの内容は、アプリを起動して、1秒間表示して、終了するだけです。

ios-simple.jsを編集します。

"use strict";

require("./helpers/setup");

var wd = require("wd"),
    _ = require('underscore'),
    Q = require('q'),
    serverConfigs = require('./helpers/appium-servers');

describe("ios simple", function () {
  this.timeout(300000);
  var driver;
  var allPassed = true;

  before(function () {
    var serverConfig = process.env.npm_package_config_sauce ?
      serverConfigs.sauce : serverConfigs.local;
    driver = wd.promiseChainRemote(serverConfig);
    require("./helpers/logging").configure(driver);

    var desired = {
      "appium-version": "1.4",
      platformName: "iOS",
      deviceName: "iPhone 7",
      platformVersion: "11.0",
      automationName: "XCUITest",
      app: "/Users/taro/projects/hello/app/Applications/HelloWorld.app",
    }; 

    return driver.init(desired);
  });

  after(function () {
    return driver
      .quit()
      .finally(function () {
        if (process.env.npm_package_config_sauce) {
          return driver.sauceJobStatus(allPassed);
        }
      });
  });

  afterEach(function () {
    allPassed = allPassed && this.currentTest.state === 'passed';
  });

  it ("test_1", function () {
    return driver
      .sleep(1000)
  });

});

7.テストケースの実行

appiumサーバの起動

Appiumデスクトップで[Start Server]しておくか、または、ターミナルで

appiumサーバの起動
$ appium &

appiumサーバの停止
$ pkill -f appium

テストケースの実行

$ cd /Users/taro/projects/hello/platforms/ios/appium-testcase
$ npm run ios-simple

iPhone simulatorの終了

$ pkill -f CoreSimulator

8.テストケース作成(座標をタップ、スクリーンショット保存)

Inspectorウィンドウで、xy座標をメモしてはクリックを繰り返して、テストケースを作りました。
次のように、座標指定のタップ、スクリーンショット保存処理、AlertダイアログのOKを追加しました。

"use strict";

require("./helpers/setup");

var wd = require("wd"),
    _ = require('underscore'),
    Q = require('q'),
    serverConfigs = require('./helpers/appium-servers'),
    fs = require('fs');

describe("ios simple", function () {
  this.timeout(300000);
  var driver;
  var allPassed = true;

  before(function () {
    var serverConfig = process.env.npm_package_config_sauce ?
      serverConfigs.sauce : serverConfigs.local;
    driver = wd.promiseChainRemote(serverConfig);
    //require("./helpers/logging").configure(driver);

    var desired = {
      "appium-version": "1.4",
      platformName: "iOS",
      deviceName: "iPhone 7",
      platformVersion: "11.0",
      automationName: "XCUITest",
      app: "/Users/taro/projects/hello/app/Applications/HelloWorld.app",
    }; 

    driver.saveScreenshot = function (path) {
      return driver.takeScreenshot().then(function(data) {
        fs.writeFile(path, data, "base64", function(err) {
          if (err) {
           throw err;
          }
        });
      });
    };

    return driver.init(desired);
  });

  after(function () {
    return driver
      .quit()
      .finally(function () {
        if (process.env.npm_package_config_sauce) {
          return driver.sauceJobStatus(allPassed);
        }
      });
  });

  afterEach(function () {
    allPassed = allPassed && this.currentTest.state === 'passed';
  });

  var tap_at = function (x, y) {
    var action = new wd.TouchAction();
    return action
      .press({"x": x, "y": y})
      .wait(100)
      .release();
  }

  it ("test_1", function () {
    return driver
      .sleep(1000)
      .saveScreenshot("/Users/taro/projects/hello/platforms/ios/appium-testcase/screenshots/01.png")

      .performTouchAction(tap_at(161, 464))
      .sleep(1000)
      .saveScreenshot("/Users/taro/projects/hello/platforms/ios/appium-testcase/screenshots/02.png")

      .acceptAlert()
      .sleep(1000)
      .saveScreenshot("/Users/taro/projects/hello/platforms/ios/appium-testcase/screenshots/03.png")
  });

});

最終的に、desired変数のdeviceName、platformVersion、appやスクリーンショット保存パスは、環境変数で渡すようにしました。
また、シミュレータでの実行が思ったより遅かったので、sleepで調整しています。

cordovaで開発したiPhoneアプリをappiumでテスト(1/2)

cordovaで開発したiPhoneアプリをAppiumでテストしたので、まとめました。

cordovaで開発したiPhoneアプリをappiumでテスト(1/2)
1.目標
2.simulator用appをビルド
3.appium他のインストール
4.Appiumデスクトップのインストール
5.Appiumデクトップを起動、Inspectorウィンドウで操作の記録

cordovaで開発したiPhoneアプリをappiumでテスト(2/2)
6.nodeでテストケース作成(アプリ起動のみ)
7.テストケースの実行
8.テストケース作成(座標をタップ、スクリーンショット保存)

当初、XcodeのXCUITestでwebviewのDOMを取得できなかったので、appiumを使ってみました。結局、appiumでもwebviewのDOMを取得できず、xy座標を指定してタップ操作を記述することにしました。それなら、XCUITestでテストケースを書いたほうがよかったかもしれません。

1.目標

全画面を遷移し、スクリーンショットを保存する。

対象機種のシミュレータ:
iPhone X、iPhone 8、iPhone 7 (11.0)、iPhone 7 Plus (11.0)、iPhone 6 (10.3)

2.simulator用appをビルド

cordovaプロジェクトの位置=/Users/taro/projects/hello
xcodeワークスペースの位置=/Users/taro/projects/hello/platforms/ios/HelloWorld.xcworkspace
appのファイル位置=/Users/taro/projects/hello/app/Applications/HelloWorld.app

ターミナルで次のsim_build.shを実行します。
app/Applications/HelloWorld.appが作成されます。

$ cd /Users/taro/projects/hello
$ ./sim_build.sh

/Users/taro/projects/hello/sim_build.sh

#!/bin/bash -x

WORKSPACE=HelloWorld
SCHEME=HelloWorld
CONFIG=Debug
SDK=iphonesimulator

xcodebuild \
  -workspace $WORKSPACE \
  -scheme $SCHEME \
  -configuration $CONFIG \
  clean \
  DSTROOT=${PWD}/app

xcodebuild \
  -workspace $WORKSPACE \
  -scheme $SCHEME \
  -configuration $CONFIG \
  -sdk iphonesimulator \
  install \
  DSTROOT=${PWD}/app

3.appium他のインストール

必要なものをインストールしてください。
ターミナルの cd する場所はどこでもかまいません。

Homebrewのインストール
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

rbenvのインストール
$ brew install rbenv ruby-build readline

RubyのパスをBashに追記
$ echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile
$ source ~/.bash_profile

Rubyのインストール
$ rbenv install --list
$ rbenv install 2.4.2
$ rbenv global 2.4.2
$ ruby -v

$ npm install -g appium
$ npm install -g appium-doctor
$ brew install carthage

環境確認
$ appium-doctor --ios

4.Appiumデスクトップのインストール

デスクトップ版 appium
https://github.com/appium/appium-desktop/releases

最新バージョンの appium-desktop-x.x.x.dmg をダウンロード、インストールしてください。

4.Appiumデクトップを起動、Inspectorウィンドウで操作の記録

Finder>アプリケーション>Appiumを起動してください。
[Simple]のまま、[start server]をクリックしてください。

黒いログコンソールが表示されます。
右上の虫メガネ[Start Inspector Session]ボタンをクリックしてください。

Inspectorウィンドウが表示されます。
Desired Capabilitiesタブで、次の5項目を設定してください。

項目
platformName text iOS
automationName text XCUITest
deviceName text iPhone 7
platformVersion text 11.0
app text /Users/taro/projects/hello/app/Applications/HelloWorld.app

platformName
“iOS”固定です

automationName
“XCUITest”固定です

deviceName
“iPhone 7″、”iPhone 7 Plus”、”iPhone 6″、”iPhone 6 Plus”などを入力します。

platformVersion
“10.3”、”11.0″などを入力します。
Xcodeで”9.3″シミュレータもダウンロード済みでしたが、appiumから”9.3″は起動できず諦めました。

app
「1.simulator用appをビルド」で作成したappファイルの絶対パスを指定してください。

[Start Session]をクリックしてください。
しばらくすると、iPhoneシミュレータが表示されます。
iPhoneシミュレータでテスト対象アプリが起動します。
Inspectorウィンドウにスクリーンショットが表示されます。

スクリーンショット上でマウスを動かしてみてください。
識別可能な画面要素が黄色くなり、クリックすると、緑になります。
ウィンドウの中央のApp Source領域には、ツリーが表示されます。
右側のSelected Element領域には、クリックした画面要素のXCUIElementツリーのxpathが表示されます。

cordovaで開発したアプリなので、画面要素はWebView内です。残念ながらDOM IDで画面要素を指定できないようです。画面要素が存在していること、属性が期待した値になっていること、などをアサーションしたいのですが、今回はあきらめました。

いろいろ試して、次の操作でテストケースを書くことにしました。

sleep(ミリ秒)
x, y座標指定のタップ
alertダイアログのOK
スクリーンショットの保存

iPhone 7でxy座標を調べて、iPhone 7 Plusなら座標を1.1倍することにし、iPhone Xは別に座標定義を用意することにしました。

画面ごとにスクリーンショットを保存し、担当者が見て確認することにしました。

(つづく)

三項演算子はデバッグしにくい

三項演算子はデバッグしにくいので、デバッグしやすさという観点では使わないほうがいいと思います。

三項演算子の例

x = (a < b) ? a : b;

if文の例

if (a < b) {
    x = a;
} else {
    x = b;
}

理由1:
デバッガでステップ実行したとき、if文のほうが処理の流れを追いやすいから。

三項演算子の文をデバッガでステップ実行すると、単に次の行に移動します。行を追っているだけでは、aとbのどちらを採用したのかがわかりません。a, b, xの値を読んだり、式を評価する必要があります。

if文をステップ実行すると、if の次に、x = a; または x = b; の行に移動します。どの選択肢に移動したのか、ひと目でわかります。

理由2:
選択肢が3つ以上になったとき、if文で書き直すから。

今は選択肢が2つですが、近い将来3つに増えるかもしれません。三項演算子で書いてあれば、if〜else if文で書き直すでしょう。それなら、今、if文で書いたほうがいいと思います。

理由3:
三項演算子を入れ子にした難解なコードを見たことがあるから。

見た瞬間、ここ触りたくねーと思いました。

この記事を書いた後、自分のソースを検索したら、予想より多く見つかりました。まあそんなもんですね。

この記事のタグは「コーディングスタイル」より「デバッガブル」だなと思い、「デバッガブル」で検索したら、いい記事が見つかりました。
デバッグしやすい、解析しやすいコードを書こう

e-Taxソフトが新しいソフトウェアのインストールを構成中です。

e-TaxソフトをWindows 7 Home Premium 64bit(FMV AH700/5A)にインストールしたところ、プログレスバーは100%まで進んだが、「e-Taxソフトが新しいソフトウェアのインストールを構成中です。」と表示したまま5分待っても終わらない。

CPU利用率は60%から25%へ下がり、HDDアクセスランプも付いていないので、インストール処理は終わっているかもしれないと思い、[キャンセル]ボタンをクリックしたが、反応なし。タスクマネージャからeTaxソフトインストーラを終了した。

スタート>すべてのプログラムに「eTaxソフト」フォルダが作成されていたが、コントロールパネル>プログラムのアンインストールの一覧に「e-Taxソフト」が見当たらない。

スタート>すべてのプログラム>eTaxソフト>eTaxソフトのアンインストールをしようとするが、「初期インストールには使えません」と表示されてしまう。

ファイルコピーはしたが、レジストリにインストール情報の登録するところでつまずいているようだ。

再度インストーラを実行すると「別のインスタンスが存在します」と表示されてしまうので、Windows再起動。

いろいろ試してみた。

インストーラexeで右クリック>管理者として実行…
結果:NG

インストーラexeで右クリック>プロパティ>互換性タブ>Windows Vista SP2
(参考 http://naked30s.com/how-to-install-e-tax-software-successfully/)
結果:NG

ノートPCにつないでいる外部モニタを外した。
結果:NG

セキュリティソフトを無効にした。
結果:NG

再起動してF8、セーフモードとネットワークで起動、インストーラexeを実行
結果:OK
途中「レジストリに登録できませんでした ??data.dll」と表示されたが、いつのまにかインストール完了まで進んだ。

リーダブルコードcakePHP版?find()の引数並びにarray()を記述しない

cakePHPの公式サイトには次のようなサンプルコードがある。引数並びにarray()を記述している。

$allPublishedAuthors = $this->Article->find('list', array(
	'fields' => array('User.id', 'User.name'),
	'conditions' => array('Article.status !=' => 'pending'),
	'recursive' => 0
));

この書き方のメリットは、下記の書き方と比較するとわかりやすい。array()を$paramsなどの変数に代入していないので前後の変数との関連を考えなくてもいいこと(下記 A,C)、この1まとまりの処理の途中に無関係なコードを記述できないこと(下記B)だと思う。

//A. これ以前に$paramsに代入しているだろうか?
$params = array(
	'fields' => array('User.id', 'User.name'),
	'conditions' => array('Article.status !=' => 'pending'),
	'recursive' => 0
);
//B. ここに無関係なコードを記述できてしまう。
$allPublishedAuthors = $this->Article->User->find('all', $params);
//C. これ以降に$paramsを参照しているところがあるだろうか?

しかし実務では次のデメリットのほうが大きいと思う。

1つ目は、引数並びが長すぎて読む気力が萎えてしまうこと。find()の閉じ括弧までが長すぎて、頭の中のスタックのプッシュ量が多い感じがする。

2つ目はデバッグしにくいこと。printデバッグしたくても、引数並びのarray()のままではvar_dump()できない。eclipse+xDebugでトレースする場合も、引数並びのarray()を表示することはできない。ソースファイルがあれば関数へステップインすると表示できるが、組み込み関数の場合はステップインもできない。

次のようにしたほうが読みやすくデバッグもしやすいと思う。

$params = array(
	'fields' => array('User.id', 'User.name'),
	'conditions' => array('Article.status !=' => 'pending'),
	'recursive' => 0
);
$allPublishedAuthors = $this->Article->find('list', $params);

さらに、array要素を1行1要素にすると、gitで直前のリビジョンとdiffしたとき変更箇所がわかりやすい。

$params = array(
	'fields' => array(
		'User.id',
		'User.name',
 	),
 	'conditions' => array(
 		'Article.status !=' => 'pending',
 	),
 	'recursive' => 0,
);
$allPublishedAuthors = $this->Article->find('list', $params);

アクション内で$this->XXX->find()を何回も呼んでいて行数が多いと感じたら、それぞれのfind()呼び出しをモデルのメソッドにするといいと思う。モデルのメソッドにすれば1行で呼び出すことができ、前後の変数との関連はないし、一連の処理の途中に無関係なコードの記述もできない。

$allPublishedAuthors = $this->Article->find_list_ArticleStatusIsPending();

なお、viewの$this->input()の2つ目の引数は、ロジックとは関係がないhtmlタグやcssなどが多く、引数並びにarray()を記述したほうが読みやすいと思う。

関連:リーダブルコード 8章 巨大な式を分割する

gitのブランチの名前の付け方

かつてSubversionを使っていたときは、ほとんどブランチを使ったことがない。慣例にしたがってtrunk、branches、tagsを用意するものの、trunkだけを使っていた。ブランチとタグの違いを理解していなかった。ブランチ操作を難しいものと思い込んでいたし、「変更履歴」と「以前の状態と比較できる」だけで満足していた。

gitを使うようになってからブランチ/マージを試してみたら、あっけないほど簡単だった。日常的にmasterブランチと開発ブランチを使うようになった。

するとブランチの名前の付け方を考えるようになった。最初はmasterとwork。次の段階では、チケット番号をつけてwork_1234 や ticket_1234で作業するようになった。この程度のざっくりとした運用で問題はないのだが、標準的なブランチ名の付け方や運用方法があるなら、知りたいと思っていた。

素晴らしい記事を発見した。ブランチは5個あるが、各ブランチの目的と運用方法が明確で迷うことはないと思う。

O-Showさんの日本語訳
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

Vincent Driessenさんの原文”A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

中央リポジトリ(例 github)

・master 現在の製品バージョン。
・develop 次回リリースの開発用。

開発者リポジトリ

・feature-* 新規機能の開発用。developから分岐し、developへマージする。
・release-* 次回リリースの準備用。developから分岐し、developとmasterへマージする。
・hotfix-* 現在の製品バージョンのバグフィックス用。masterから分岐し、developとmasterへマージする。

※このブランチモデルをベースにしたgit-flow というプラグインもある。

整ったコードの7か条

「ビューティフルコード」 32章 働くコードの「整ったコードの7か条」を紹介する。
#は、投稿者(青木)の意見。

32章の著者 Laura Wingerd、Christopher Seiwald

原文
http://www.perforce.com/resources/white-papers/seven-pillars-pretty-code

サンプルコード
ftp://ftp.perforce.com/jam/src/make.c

■既存のスタイルに溶け込むこと
コードを変更するとき、既存のスタイルで書くこと。

「本のよう」であること
1行の長さを短くする。短い行ほど理解しやすい。 経験的に80文字がよい。

コードをブロックに分けること
コードにコメントをつけること

# サンプルコードはstep 1、step 2と大ブロックに分け、step 1の中をstep 1a、step 1b と小ブロックに分けている。

ごちゃごちゃにしないこと

繰り返し参照される変数名を短くする。
元のコードをコメントで残すのではなく削除する。元のコードはSCMを見ればよい。
何を変更したかをコメントしない。変更履歴はSCMを見ればよい。

# gitやバグ管理ツールを使うと、不要コードや不要コメントを思い切って削除できるようになる。

似たものは似ているように見えるようにすること

インデントを克服すること
インデントが深いと読みにくくなる。
しかし、最大の落とし穴は「入れ子」であり、「入れ子」になったコードは理解しにくい。

# 「入れ子」が深いと、頭のスタックがオーバーフローしてしまう。

Another HTML-lint htmllint.cgiをCentOS/5.5に設置する

Another HTML-lint
http://openlab.ring.gr.jp/k16/htmllint/htmllinte.html

Another HTML-lintはHTML文法チェッカーの老舗であり、Perlソースが公開されている。VMWare上のCentOS/5.5(32bit版)への設置手順を説明する。

[動作環境]

・Windows7上のVMWareにCentOSをインストールした。
・CentOSのIPアドレスを 192.168.0.4 とする。
・WindowsのWebブラウザで、http://192.168.0.4/ にアクセスすると「Apache 2 Test page powered by CentOS」と表示されること。

(1) Windows上の作業

●htmllint.zipをダウンロードする。(記事投稿時2011-11-28 16:17版)

●zipファイルを解凍すると、htmllint/ の下にディレクトリ階層なしで全ファイルが展開される。

●htmllintenv を htmllint.env へコピーまたはリネームする。

●htmllint.cgi、taglist.cgi の先頭行(perlパス)を編集する。

編集前

#!/usr/local/bin/perl

編集後

#!/usr/bin/perl

(2) WindowsのWinSCPで、CentOSへアップロード

●/var/www/cgi-bin/htmllint/htmllint.cgi の位置へ全ファイルをアップロードする。

●htmllin.cgi、taglist.cgi のアクセス権限を755 に設定する。

○WindowのWebブラウザで、http://192.168.0.4/cgi-bin/htmllint/htmllint.cgi を開き、「Another HTML-lint error!」と表示されるか?

サーバエラー → (1) と (2) へ

○WindowsのWebブラウザで、http://192.168.0.4/cgi-bin/htmllint/htmllint.html を表示できるか?

できない →(3)へ

○htmllint.htmlのURL欄に「http://www.yahoo.co.jp」を入力し[check]する。結果が表示されたか?

「調整中です」 →(4)へ

(3) CentOSでsshログイン作業

CentOSインストール直後は、/cgi-bin/ 下は *.cgi、*.pl以外は表示できない。htmlやcssを表示できるように/etc/httpd/conf/httpd.confを編集する。

編集前

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>

編集後

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
    AddHandler text/css css
    AddHandler text/html html
    AddHandler image/gif gif
</Directory>

●webサーバを再起動する。

[root@192.168.0.4]# service httpd restart

○WindowのWebブラウザで、http://192.168.0.4/cgi-bin/htmllint/htmllint.html を表示できるはず。

(4) CentOSでsshログイン作業

gccとPerlモジュールをインストールする。いろいろ聞かれたら yes または y を入力して進める。

[root@192.168.0.4]# yum -y install gcc
[root@192.168.0.4]# cpan
cpan> install Jcode
cpan> install CGI
cpan> install LWP
cpan> exit

○WindowsのWebブラウザで、http://192.168.0.4/cgi-bin/htmllint/htmllint.html を表示し、URL欄に「http://www.yahoo.co.jp」を入力し[check]する。結果を表示できるはず。

デプロイ先を切り替えてgit aws.pushする

【環境】

PC: Windows7、git、AWS Elastic Beanstalk Command Line Tool
サーバー: AWS ElasticBeanstalk

AWS ElasticBeanstalk(以下EBT)はロードバランサーとオートスケーリングサーバのパッケージである。コマンドプロンプトのgit aws.configでデプロイ先を設定し、git aws.pushでデプロイする。

デプロイ先が一つだけなら最初に1回だけgit aws.configをすればいいのだが、デプロイ先として本番環境、ステージング環境、開発環境など複数ある場合、毎回aws.configするのは面倒である。ここではデプロイ先を切り替えてgit aws.pushする方法を説明する。

環境1
AWSアカウント1>EBT>Application=hoge1-app>Enevironment=hoge1-env
環境2
AWSアカウント2>EBT>Application=hoge2-app>Enevironment=hoge2-env

【方法1】

環境1用のgitフォルダD:\hoge1、環境2用のgitフォルダD:\hoge2と別々に用意する。リモートリポジトリを経由してD:\hoge1とD:\hoge2を同期する。

D:\hoge1で開発作業、commit
D:\hoge1で環境1へgit aws.push

D:\hoge1でリモートリポジトリへpush

D:\hoge2でリモートリポジトリからpull
D:\hoge2で環境2へgit aws.push

※リモートリポジトリ
インターネットを介して複数人で作業する場合はgithubが便利である。無料プランは非公開リポジトリを作成できないが、有料プランにすると非公開リポジトリを作ることができる。
一人gitでLAN内作業の場合は、共有ドライブ(ローカルドライブでもよい)が手軽である。エクスプローラ右クリック>Git Create repository here>[Make it Bare]のチェックを付けると、リモートリポジトリが作成される。Git syncのRemote URLに共有フォルダのパス(Z:\gitrepos\hogeなど)を指定すればよい。

【方法2】

1つのgitフォルダ(以下、hogeとする)でデプロイ先を切り替える。

git aws.configは、hoge\.elasticbenstalk\configに設定内容を保存し、git aws.pushはこのconfigにしたがってデプロイする。

hoge\.elasticbenstalk\config

[global]
ApplicationName=hoge1-app
CredentialFile=C:\Users\taro\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge1-env
Region=ap-northeast-1

そこで環境ごとのconfigファイルを用意しておき、バッチファイルでconfigにコピーし、git aws.push する。

まずconfigをコピペして、環境1のconfig-hoge1-env、環境2のconfig-hoge2-envを作成する。AWSアカウントが複数ある場合は、それぞれのaws_credential_fileも用意しておく。

hoge\.elasticbenstalk\config-hoge1-env

[global]
ApplicationName=hoge1-app
CredentialFile=C:\Users\taro\aws\account1\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge1-env
Region=ap-northeast-1

hoge\.elasticbenstalk\config-hoge2-env

[global]
ApplicationName=hoge2-app
CredentialFile=C:\Users\taro\aws\account2\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge2-env
Region=ap-northeast-1

次にバッチファイルを作成する。

hoge\git_awspush_1_hoge1-env.bat

copy .elasticbeanstalk\config-hoge1-env .elasticbeanstalk\config
git aws.push

hoge\git_awspush_2_hoge2-env.bat

copy .elasticbeanstalk\config-hoge2-env .elasticbeanstalk\config
git aws.push

環境1へデプロイしたいときは、hoge\git_awspush_1_hoge1-env.batを実行(またはダブルクリック)し、環境2へデプロイしたいときは、hoge\git_awspush_2_hoge2-env.batを実行(またはダブルクリック)する。