Date:  Wed, 08 Dec 2010 18:09:25 +0900
Subject:  【オブジェクト倶楽部: 2010-46号】
X-Mail-Count: 00364

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.354 2010/12/08

■ I N D E X
┃
┣【Topics】セミナーを開催します(1/21)
┣【アジャイル】アジャイル・プラクティスの見つけ方 [20]
┃              〜許可を求めるな、謝罪せよ。〜
┣【プログラミング】nginxから始めるWebサーバー構築入門 [5]
┗ 編集後記

┌▼JaSST'11 Tokyo:ソフトウェアテストに関する国内最大級のシンポジウム!▼─┐
│【1/25,26 開催】リー・コープランド氏による基調講演、論文や事例発表に  |
| テストツール紹介、パネルやチュートリアル等、ご満足のいく企画の数々  │
│  【詳細、お申し込み】 http://jasst.jp/archives/jasst11e.html     |
└■ 【開催場所】目黒雅叙園(東京・目黒)                ■┘

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇 セミナーを開催します(1/21)
  〇 〇━━━━━━━━━━━━━ ━━・ 

『PMBOK(R)とチームファシリテーションの融合
  〜自律的なチームを管理する考え方と方法〜』
日 時:2011年1月21日(金) 13:00〜18:30(12:40受付開始)
場 所:ふくい南青山291(東京都港区南青山5丁目4-41グラッセリア青山内)
対 象:プロジェクトマネジャー、プロジェクトリーダー、チームリーダー

▼プログラム
1.PMBOK(R)の概要とTFを実現するプロジェクトマネジメント計画
2.チームファシリテーション
3.ワーク
4.全体ふりかえりセッション

▼詳細情報およびお申込みはコチラ↓
/event/#upcoming

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【アジャイル】アジャイル・プラクティスの見つけ方 [20]
┗              〜許可を求めるな、謝罪せよ。〜


こんにちは。こんぴろです。突然ですが3Mの社是には「許可を求めるな、謝罪
せよ。」[*1]というものがあるそうです。チェンジビジョンでも2年くらい前に
弊社代表の平鍋さんからそういう話を聞き、僕は仕事の中で実践するように努
めてきました。

話を聞いた当初、「許可を求めるな」と言われても、それはなかなか難しい事
のように思えていました。と言うのも、僕は昔から臆病なところがあり、一人
でなんでもかんでも進める事に怖さを感じていたのです。

「もしかすると今からしようとしている事は本当にみんなの役に立つだろうか」

なんて事を気にしたりしていました。だから周りにとりあえずやってみたらど
う思うか、聞いて回る事が多かったのです。ただ、周りもそのアイディアを実
施すると何がどう変わるのか、話を聞いてもそのうれしさが分からない場合が
多いようです。

そこで先月、毎日行っているデイリービルドの結果を朝会で報告する事をして
みました。デイリービルドとは毎朝ビルドとテストを行う事です。CIも行って
いますが、環境をまっさらにした後ビルドを行うような、時間のかかるビルド
プロセスは1日1回朝に行うようにしています。こういったビルドプロセスは少
しずつ改善してきたのですが、ビルド結果が失敗したときにどうしていくのか、
チームとしてきちんと話し合えていなかったのです。

今回は、周りには許可を求めず、特に相談することもしませんでした。うちの
チームでは昨日やった事、今日やる事、今抱えてる問題をブログに記述し、毎
朝みているのですが、その他に、ビルド結果のスクリーンキャプチャをブログ
に貼付けておいたのです。そしてそれを毎朝見るようにしてみました。

その結果、僕が毎朝それをやるのも変だ、という話が出て、今は、朝会の司会
がビルド結果を表示し、みんなで見る事になりました。そしてその場でどのテ
ストが失敗しているかを見て、テストの修正の担当をサインアップするように
なってきました。ただ結果が出るだけではなく、そういう運用をしていくよう
に変わっていったのです。

デイリービルドなどはツールを使って自動化するだけでも結構手がかかったり
します。なので環境を用意するのも一苦労だったりしますが、せっかく環境を
用意してもあまり見向きもされないのではもったいないでしょう。チームで問
題に向き合う運用ができる事が重要だと思うのです。ふりかえりでそうしてで
きた流れはやっぱりいいものだ、と言ってくださった方もいました。

ところで丁度その頃のオブラブのメルマガの平田さんの記事[*2]に、毎朝上司
が日次でページを作成しており、「それはcronでやった方がいい」という話が
メンバーから出たプロジェクトの話がありました。僕はその話を読んで、機械
が自動で行う事と、人によって行われる事とで、意識付けが変わるというよう
に感じられました。人の手が介在する事で気持ちが変わってくるのです。

どういう事かと言うと、毎朝担当の人がビルドの結果を見に行く事で、落ちて
いるテストがなんだったのか、どういう原因で落ちているのか、目にします。
僕の場合は、テストが失敗している場合などを目にすると気になる性格なので、
朝会が始まる時間まで5分程度調べます。5分で原因が分かれば儲けもんですし、
分からなければ分からないで、それを伝えればいいのです。

しかし機械により自動化されていたとしても、機械がそこまで調べてくれるわ
けではありません。先述した平田さんの上司の方は、毎朝その日のページを作
る事で、昨日やった事を毎日目にしていたのかもしれません。人手を介す事は
そういった効果があるように思えます。

最後は少し脱線したかったので、パターンを省きました。また「許可を求める
な、謝罪しろ」は、本来は、「失敗をおそれて許可を求めるよりは、実際に実
行して失敗から学ぶほうがいい。」という意図で語られる言葉のようです。今
回の例は厳密には間違っているかも知れませんが、そこはご容赦ください。次
回もお楽しみに。(こんぴろ)

[*1]「許可を求めるな、謝罪せよ。」の原文はこちらです。
     http://bit.ly/glE4xN
[*2] 要求とか要件についての四方山話 [7]
     /ml-arch/magazine/360.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】nginxから始めるWebサーバー構築入門 [5]

こんにちは、hsbtです。

今回はnginxをwebサーバーとしてではなく、リバースプロキシとして動作させ
る方法について紹介します。

● リバースプロキシとは
リバースプロキシとは、Webサーバーより手前に設置し、以下のような機能を提
供することを目的としています。

* セキュリティの強化
* 複数のWebサーバーへのアクセスの振り分け
* Webサーバーの静的コンテンツのキャッシュ

具体例として、RailsアプリケーションをWebサーバーで動かしている場合を想
定して、nginxをアクセス振り分けを行うリバースプロキシとして、用いてみま
しょう。

● nginxでアクセスの振り分けを行う
nginxでアクセスの振り分けを行う場合はHttpProxyModuleを用います。
例えば、Railsアプリケーションがlocalhostの3000ポートで動作している場合
に一度nginxがアクセスを受ける場合は、以下のような設定をlocationディレク
ティブに記述します。

location / {
 proxy_pass        http://localhost:3000;
 proxy_set_header  X-Real-IP  $remote_addr;
}

proxy_passでは、nginxに対するアクセスを何処に転送するかを記述します。こ
こではhttpを含めたフルパスを記述する必要があります。proxy_set_headerで
は転送先に対してリバースプロキシとして動作しているnginxのIPアドレスでは
なく、nginxに対してアクセスがあったIPアドレスをHTTPヘッダにセットしてい
ます。

基本的な使い方は上記となりますが、このままでは単一のサーバーに対するア
クセス転送しか実現できません。複数のサーバーに対してアクセスを振り分け
る場合はHttpUpstreamModuleモジュールを用います。HttpUpstreamModuleを用
いて複数のサーバーに振り分ける場合のnginx.confは以下のような内容となり
ます。

upstream backend  {
 server primary:3000
 server secondary:3000
 server localhost:3000
}

server {
 location / {
   proxy_pass  http://backend;
 }
}

上記の例では、backendという名前のサーバーの集合を定義し、nginxに対して
行われたアクセスをprimary、secondary、localhost、それぞれの3000ポートへ
ラウンドロビンで振り分けを行っています。サーバーのラウンドロビンの設定
を詳細にすることでサーバーの振り分けを柔軟に変更することができます。今
回の連載では詳細設定については省略しますので、興味のある方は公式ドキュ
メントを参照してください。
http://wiki.nginx.org/HttpUpstreamModule

● unicornとの連携
それでは、HttpProxyModuleとHttpUpstreamModuleを用いてUnicornで動作させ
ているRailsアプリケーションへのアクセスを振り分けてみましょう。

unicorn (http://github.com/defunkt/unicorn) はgithubで使われているRack
インタフェースに標準準拠しているアプリケーションサーバーです。
インストールはrubygemsを用います。

$ gem install unicorn

インストール完了後にRailsアプリケーションのルートディレクトリ(RAILS_ROOT
またはRails.root)でunicorn_railsコマンドを実行するとRailsアプリケーショ
ンがunicorn経由で起動します。今回は複数のサーバーへの振り分けを確認した
いので、3000ポートと3001ポートでunicornを起動させてみます。

$ unicorn_rails -l 3000 -l 3001

worker=0 readyと表示されれば正常に起動しています。unicornには単純にRack
アプリケーションを起動するだけではなく、passengerとは異なるアプローチの
様々な機能が提供されています。こちらも今回紹介するには紙面が足りません
ので、興味のある方は公式ドキュメントを参照してください。
http://unicorn.bogomips.org/

それでは起動中のunicornに対してnginxをリバースプロキシとして動作させて
みましょう。設定ファイルは以下のような内容となります。

 worker_processes  1;

 events {
    worker_connections  1024;
 }

 http {
    include       mime.types;
    default_type  application/octet-stream;

    upstream backend  {
      server localhost:3000
      server localhost:3001
    }

    server {
        listen       80;
        server_name  localhost;

        location / {
          proxy_pass  http://backend;
        }
    }
 }

上記の設定内容をnginx.confとして保存した後にnginxをスタートさせ、localhost
にアクセスすると、unicornで起動してRailsアプリケーションが起動すると思
います。今回は同じlocalhost内のポートを別にしただけの場合を想定した例と
なりましたが、実際の環境でアプリケーションを動作させる場合は複数のサー
バーを利用します。そのような場合はHttpUpstreamModuleの例で示したように
server名称としてlocalhost以外の名称を指定しましょう。

今回は、nginxをリバースプロキシとして動作させる方法を紹介しました。これ
までの紹介でnginxをWebサーバーとして動作させる方法から、Railsアプリケー
ションを動かす方法、モジュールの利用のような基本機能をひととおり紹介し
終わったので、連載は一度お休みにしたいと思います。次回もnginxのような運
用周りのノウハウを紹介する連載を行いたいと思いますので、期待してお待ち
ください。(hsbt)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人のナガタユウコです。みなさまお待たせしました、オブラ
ブ特製カレンダー2011が完成しました!こちらを、いつも本メルマガをご愛読
いただいている読者のみなさまにプレゼントします☆先着50名様限りとなって
おりますので、ご希望の方は下記のフォームから急いでご応募ください!みな
さまのご応募、お待ちしております!(ナガタユウコ)
▼オブラブカレンダー2011 プレゼント応募はコチラから↓
http://bit.ly/oblove-calendar-2011

*** オブラブスタッフ自己紹介 ***
No.31 岡島
( @okajima_yukio , http://d.hatena.ne.jp/HappymanOkajima/ )
オブジェクト倶楽部メルマガ読者のみなさん、こんにちは。
岡島です。

オブラブメルマガで「現場リーダーの心得」という連載を持っています。おか
げさまで先日30回目に到達しました。一口に30回といっても2年以上は続いてる
んじゃないかなぁ、よく続いてるなぁ、と我ながら思ってます。ちなみに数年
前に、イベントで話をしたこともあります。LTは出たことないかも。後、懇親
会で乾杯する機会もなぜか多い気がしてます。

以前は「クワガタ部長」と呼ばれるほどクワガタのブリードにはまってました
が、最近は落ち着き気味です。やっぱり数が増えすぎて一匹当たりにかけられ
る時間と愛情が目減りしてしまったのが原因です。とはいえ、今飼っているオ
オクワガタは大事に育て、天寿を全うさせてやりたいと思ってます。幼虫の時
から数えると4年くらいの付き合いの個体もいるのです。

かわりにここ2年ほどまじめに取り組んでいる趣味と言えばボクシングのトレー
ニングです。試合に出ようというつもりはないのですが、週に一度は部活のよ
うに仲間内で練習しています。つい最近も殴られて鼻血が出てしまいました。
が、これも一人前に扱ってもらえるようになった証だと思って頑張ってます。
何かの本にも書いてありましたが、「自分が一番下手な環境」が、一番成長で
きますね。

最後に仕事の話を少々。仕事は以前は業務系メインだったのですが、今は組込
み系がメインです。業務系と組込み系ではエンジアの値観や仕事のスタイルな
どといった文化がかなり違うと感じます。どちらがいい・悪いではなくて、そ
れぞれに合った価値観があるんですよね。今は、お互いの良いとこどりをする
ことが、自分たちの仕事だと思って取り組んでいます。(岡島)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.