┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.345 2010/09/29
■ I N D E X
┃
┣【プログラミング】nginxから始めるWebサーバー構築入門 [3]
┣【プログラミング】Let's Try 受入テスト [9]
┗ 編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】nginxから始めるWebサーバー構築入門 [3]
こんにちは、hsbtです。
今回は前回に引き続きnginxのコマンドラインオプションと設定ファイルについ
て解説をしたいと思います。
前回のメルマガではnginxの-sオプションを使用してnginxのプロセスを再起動
する操作を行いました。-sオプションを付けてnginxを実行すると、起動中の
nginxのプロセスに対して-s以降に記述した内容のsignalを送ります。
このsignalには以下の4種類があります。用途についても解説します。
- stop : プロセスを即座に終了します。
- quit : プロセスが何らかの処理を行っている場合に完了するまで待ってか
らプロセスを終了します。
- reload : 設定ファイルを読み込み直します。
- reopen : ログファイルを開き直します。
基本的にnginxのようなWebサーバーは無停止で動かすことを前提に設計されて
いますので、通常はreloadを用いるだけで十分でしょう。また、nginxには-sオ
プションを用いたsignal送信ではなく、unix標準の機能を用いてsignal送信す
ることで、上記の4つよりさらに詳細な制御が可能です。本連載での紹介は割愛
したいと思いますので興味のある方はnginxの公式サイトのドキュメントを参照
してください。
http://wiki.nginx.org/NginxCommandLine
続いて-gオプションについて、解説したいと思います。-gオプションは続けて
設定ファイルのディレクティブの内容を指定することで、設定ファイルの内容
を上書きしてnginxのプロセスを動作させることが可能となります。
例えば、試験的にworker processを2つにしてnginxを動かしたい時には以下の
ように指定します。
nginx -g "worker_processes 2;"
常に変更内容を用いる場合には設定ファイルの内容を書き換えるべきですが、
上記のようにちょっとした挙動の変化を確認する場合には-gオプションは便利
です。
コマンドラインオプションの解説は以上です。次にnginxの設定ファイルでよく
利用されるコンテキストとディレクティブについて解説したいと思います。
nginxでよく使われるコンテキストはhttp、server、locationの3つです。これ
らのコンテキストに記述する設定内容について以下に解説します。
- http : Webサーバーとして共通の設定、MIME Type等
- server : バーチャルサーバーごとに異なる設定、listenやserver_name等
- location : URLごとに異なる設定、rootやindex等
上記のコンテキストを全て使った設定ファイルは以下のようになります。
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
server {
listen 3000;
server_name localhost;
location / {
root /var/www
}
location /foo {
root /var/www2
}
}
}
上記の例ではhttpとしてmime.typesに記載されている内容を取り込み、Webサー
バーの応答ポートとして3000番、サーバー名はlocalhostを指定しています。
また、URLとして http://localhost:3000/ が指定された時は /var/www 、
http://localhost:3000/foo が指定された時は /var/www2 が、ドキュメントの
ルートとして用いられます。後者の場合、実行時には /var/www2/foo が参照さ
れます。
※rootディレクティブはWebサーバーが参照するコンテンツの相対パスの起点と
なるディレクトリを変更する場合に利用します。
今号までの設定ファイルの知識を活かして、次回はRailsアプリケーションを
nginxで動かすための準備と設定ファイルの書き方について紹介したいと思いま
す。(hsbt)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [9]
● はじめに
本連載は、ツール編に入り、Cucumberについて解説しています。
今回は、Scenario Outline: & Examples:の記述方法について解説します。
Cucumberについては過去の連載 を参考にしてください。
- /ml-arch/magazine/345.html
- /ml-arch/magazine/349.html
● Scenario Outline:
Scenario Outline: & Examples:は、システムの期待する振る舞いを、シナリオ
のステップを具体例ではなく、アウトライン(テンプレート)で記述し、具体例
を、表形式でまとめて記述する方法です。
ステップの入出力パターンが多数存在する場合、表を使った方が簡潔にわかり
やすくシステムの期待する振る舞いが記述できるため、便利な機能です。
● 記述例
<cucumberのインストール先>/examples/i18n/en/features/addition.feature
を参照してください。
== <cucumberのインストール先>/examples/i18n/en/features/addition.feature ==
....
Scenario Outline: Add two numbers
Given I have entered <input_1> into the calculator
And I have entered <input_2> into the calculator
When I press <button>
Then the result should be <output> on the screen
Examples:
| input_1 | input_2 | button | output |
| 20 | 30 | add | 50 |
| 2 | 5 | add | 7 |
| 0 | 40 | add | 40 |
==================================================
Scenario Outline:とExamples:の2つに分け、Examples:側で、表形式を記述し
ていることが読み取れます。
(「Scenario:」ではなく、「Scenario Outline:」と記述している点に注意して
ください。)
また、Scenario Outline:側で、<input_1>,<input_2>,<button>,<output>と記
述されている箇所と、表のカラム(input_1,input_2,button,output)が対応して
いることが上の記述から読み取れます。
cucumber実行時の際は、Examples:の行単位で、Given,When,Thenのステップを
実行します。例えば、最後の行であれば
Given I have entered 0 into the calculator
And I have entered 40 into the calculator
When I press add
Then the result should be 40 on the screen
のテストのステップが実行されます。
ステップをアウトライン化し、具体例を表形式で、まとめて記述していること
が、上の記述から読み取れるでしょう。
● まとめ
Scenario Outline: & Examples:について解説しました。
Scenario Outline: & Examples:は、システムの期待する振る舞いを、直接具体
例をステップで記述するのではなく、シナリオのステップを具体例ではなく、
アウトライン(テンプレート)で記述し、具体例を、表形式でまとめて記述する
方法です。
Cucumberでは、Scenario Outline: & Examples:の他に、別の表形式を使った記
述方法を用意しています。
(例としては、実行結果が表形式の場合、期待値も表形式で記述したい。)
次回は、その表形式を使った記述方法について解説します。(IENAGA)
● 過去の連載
1) /ml-arch/magazine/316.html
2) /ml-arch/magazine/321.html
3) /ml-arch/magazine/325.html
4) /ml-arch/magazine/330.html
5) /ml-arch/magazine/334.html
6) /ml-arch/magazine/338.html
7) /ml-arch/magazine/345.html
8) /ml-arch/magazine/349.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。急に寒くなりましたね。風邪を引か
ないよう温かくしなくては、と、先日秋用のお布団を出しました。ぬくぬくし
ていくらでも眠れそう・・・☆と感じたのは私だけではなかったらしく、うち
で飼っている猫もお布団の上で丸くなってずーっと眠っています。最初はかわ
いいなぁと思っていたのですが、朝、仕事に行くために私がお布団から出る時
にもまだ幸せそうに寝ている猫を見ると、なんだかくやしくなってしまいまし
た＞＜ 私も猫みたいに一日中寝ていたいです！(ナガタユウコ)
*** オブラブ2010カレンダー公開 ***
10月「Scrumの登場人物」
/special/#calendar
今月のカレンダーも先月に続いてスクラム(Scrum)がテーマです。今回はScrum
で述べられている役割について書いてみました。
Scrumは、プロジェクトの関係者をチーム、プロダクトオーナー、スクラムマス
ターの3つの役割に分けており、それぞれの役割の責務を明確に定義しているの
が特徴の1つです。
詳しい説明はカレンダーを読んでいただくとして、何故Scrumはプロジェクトの
関係者を3つに分けたのでしょうか？これらの登場人物を実際の現場で実現でき
るのか？
また、Scrumではこれらの役割を兼務しても良いと述べているのですが、プロダ
クトオーナーとスクラムマスターは兼ねてはいけないと述べています。それは
何故でしょうか？
Scrumは、実は開発プロセスではなく、複雑なプロダクト開発を可能にしていく
ためのフレームワークです。そのため、今回の登場人物のように現場で色々と
考えていくための切っ掛けがたくさんちりばめられています。
今回のカレンダーの記事が、みなさんの現場が良くなる切っ掛けの1つになれば
幸いです。(nawoto)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.