動作させるRailsアプリケーションの環境を指定します。応じてdevelopmentなどを指定します。次回はpassengerと並んで近年注目されているunicornをnginxのproxyモジュールを利用して動かす方法を紹介したいと思います。〜壁に大事な情報を貼り出す〜こんにちは。10月も終わりですね。先日福井に行ってきました。夏場は東京の暑さとあまり変わりないと聞いていましたが、この季節になると東京よりも肌寒かったです。福井に行ったかと言うと、自分の所属するプロジェクトは、福井と東京で分散開発を行っていますが、この度新しいメンバーが参加する事になりました。前にリリースが無事に終わった事もあり、その打ち上げもかねて、福井で顔合わせ会を行う事になったのです。今、福井の事務所では、astah*のアーキテクチャ図[*1]を壁に貼っています。これは、新しく参加するメンバーとastah*の構造を共有する意図で作成したものです。プロジェクトメンバーみんながアーキテクチャ図の前に集まり、開発リーダーから簡単な説明を聞き、その場で質問を行うような場が今回の出張にはありました。その結果、僕自身もあやふやだった、どのレイヤでどういった実装をすべきかが、確認できました。新たに参加されたメンバーからは直接感想を聞いたわけではないのですが、あらかじめアーキテクチャを聞いておくことで防げることがあります。装を防ぐことができるでしょう。いう事はコードを追いかけるだけでは分からない部分です。全体を俯瞰した絵が用意されていて、その前に集まり、話をすると、既存の開発者も意見を交換でき、僕はいろいろと理解ができました。PCの中では付加情報を書き込むのが大変ですが、壁に貼られたアーキテクチャ図であれば、書き込むのも簡単です。容の更新はそれほど多くはありません。チェンジビジョンのクレドには「壁に貼る」があがるほど、壁に情報を貼り出す事を多く実践してきたのですが、アーキテクチャ図を貼り出す事で議論の進みがここまで変わるとは思いもよりませんでした。言う事で、プラクティスにまとめます。「システムのアーキテクチャ図を壁に貼り出す」アナログの良さは画面に縛られないところにあります。これまでの設計をまとめ、壁に貼り出す事で、メンバー間のアーキテクチャに対する考えを引き出し、より良いデザインをチームで作っていきましょう。ない実装をする事を少なくすることができます。一般にアーキテクチャは、限られた人数で考えられるべきです。「船頭多くして船山に登る」ということわざもある通り、意見がまとまらず、ちぐはぐなアーキテクチャになる事が多いと言われています。----------------------------------------------------------------------今回はastah*のアーキテクチャ図を貼り出している例をご紹介しました。┗編集後記こんにちは、編集人のナガタユウコです。なんだか突然真冬かと思うような寒さになりましたね。***11月「スクラムのプラクティス」http://ObjectClub.jp/special/#calendar3ヶ月連続でお届けしたスクラム(Scrum)特集もいよいよ最終回です。今回はスクラムが採用しているプラクティスと進め方について書いてみました。手に取って読んでいただけると分かりますが、スクラムは計画、進捗、課題に関するプロジェクトの運営についてのプラクティスを中心に採用しています。逆にXPでは中心となっているエンジニアに対するプラクティスは、ほとんど何も定義していません。これは何故でしょうか?スクラムは、こういう部分を採用する現場で考えていってもらうのが、目的であり楽しい部分になっています。一度、みなさんの現場でも考えてみてはいかがでしょうか?今回のカレンダーがその切っ掛けになれば幸いです。軽にオブラブのイベントや勉強会等で声を掛けていただければと思います。