SymfonyをDocumentRoot以外で動かす

Symfonyのプロジェクトディレクトリにはwebというディレクトリが用意されていて、標準のインストールマニュアルではそこをDocument Rootに指定するようにと記載 されています。

ただ、新規にWebサービスを立ち上げるような状況であれば、それも問題ないものの既存環境にSymfonyをインストールし、Document Rootを変更することでそこで動かしていたアプリケーションなどに影響が出るといった場合は、別のディレクトリでSymfonyを動作させたいということが出てきます。

※ ここでは、Symfony1.4.8でOSはLinuxを想定した設定方法を記載しています。

SymfonyのDocumentRootをwebディレクトリ以外に設定する

まず、Apacheの設定を下記のように変更します。

Alias /apps/sf "/path/to/install/symfony/web/sf"
<Directory "/path/to/install/symfony/web/sf">
    AllowOverride All
    Allow from All
</Directory>
Alias /apps/ "/path/to/symfony/pjdir/web/"
<Directory "/path/to/symfony/pjdir/web">
    AllowOverride All
    Allow from All
</Directory>

上段の「/path/to/install/symfony/web/sf」は、Symfonyのインストールディレクトリで、この設定は標準の設定方法と変わりはありません。

下段の「/path/to/symfony/pjdir/web/」は、Symfonyのプロジェクト用のディレクトリへの設定ですが、その上にAliasで任意のパス名（apps/）を指定するとwebディレクトリが参照されるように設定しておきます。

次に、webディレクトリ内にある.htaccessファイルを編集します。

# no, so we redirect to our front web controller
RewriteRule ^(.*)$ /apps/index.php [QSA,L]

Apacheの設定で、URL上ではapps/以下のアクセスでwebフォルダを参照するようにエイリアスを作成しているので、同様にwebディレクトリ内にあるindex.phpへのアクセス方法も編集しておきます。

今回の設定の場合、「example.com/apps/」でSymfonyのwebディレクトリへアクセスできるようになります。

現在別のフレームワークで運用しているとか、他のCMSが入っているなどいった場合に、既存の環境を壊すことなくSymfonyを導入することができます。

また、Symfonyへの移行が完了したからDocument Rootを変更したいといった場合でも、上記の設定を元に戻すだけで対応も可能になります。

[PR]★ロリポップ！★WordPressやMovableTypeの簡単インストール、cron、共有SSL対応！

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

[PR]So-netでauひかり！今なら20,000円キャッシュバックキャンペーン実施中！

関連記事

[Symfony] setFlashしたはずのセッションデータが突然消える現象への対応

[ Symfony ] インストールしてHello Worldを出すまでの3ステップ

PHP_CodeSnifferでコーディング規約に準拠しているかチェックをする

PHPのプログラムをデーモンとして動かしてくれるPEAR::System_Daemon

PHPで利用できる関数やクラス、定義済みの定数や変数を表示する

PHPでブラウザのキャッシュを利用させる検証

[Smarty] テンプレートファイル用ディレクトリをカスタマイズする

mod_actionsを使ってドキュメントや画像、Flashファイルを保護する

内製化することの幻想と現実

かなり高機能なライブラリが無料で提供されたり、便利なサービスのAPIが公開されていたり、ブログを見渡せば技術系のネタが転がってたり勉強会資料が公開されていたり・・・と、そういった情報を持ってしたら一昔前に比べたら格段に簡単にシステム自体を構築できるような状況にはなっています。

であれば、内製化というのは脚光を浴びるような状況になっているのかなとも思ったりしますが、クラウドサービスの流行なんかを見たらより低コストでサービスの構築ができますよのうたい文句の元、あまりそういった状況にはなっておらず、どちらかというと内製化というのは不景気のあおりを受けて予算が無いから自社でやるかといったネガティブな方向で決まっていっている状況になっている気もします。

内製は楽しいか

って答えはもちろんYESで、やはり自分たちで仕様の決定権をある程度の範囲で与えられて、一から環境を構築していく状況というのは、エンジニアからすれば凄くやりがいが出るでしょうし、愛着もわいてきたりするもんです。

「これは内製でやるべきか、外注でやるべきか？」って質問をされれば、よっぽど仕様がひどくってデスマ突入フラグが目に見えてわかるような状況を除けば、どのエンジニアでも構築は自分たちの手でしたいと思うのではないでしょうか。

作る楽しさを感じていたり、構築をすることこそが自分たちの役割なんだというようなある意味、極端に偏った視点を持ってたりもするので、そもそもその構築自体のお仕事を取り上げられたらどうなるんだろうと不安を覚えることもあったりします。

下請けに丸投げして、そのプロジェクト管理をするといったような仕事は嫌いますし、エンジニアとしての仕事からすれば遠くかけ離れたような気分にもなるもんです。

しかし、そのような外注か内製かといった決定権は当のエンジニアにはもちろんなく、そのプロジェクトを管理する上の立場の人たちが握ってたりもするんですけど、そういった人たちは（当たり前かもしれませんが）ひどく論理的な思考をして予算や効果や実行リスクなどの判断から外注にするか内製にするかの決定を行います。

場合によっては、内製化を頭から否定して「構築するのは全て外に投げて、君たちはもっと上位の高度な仕事をしてもらいたい」というような自分のポリシーで役割が決まってきたりもします。

上位の高度な仕事って大体プロジェクト管理だったりして、その内容はExcel弄ってたりするだけだったりもするんですけどね・・・。

ひどく論理的に物事を考える意思決定者はエンジニア畑じゃなかったりする場合もあるので、そういった人たちにはそもそもエンジニアが物作りの楽しさなんてものは知らなかったりするので、それを説いたところで大方理解はしてくれません。

どちらかというと、内製化することで社内のシステム開発のロードマップをどうするかとか、長期計画の中で内製化することのメリットや外注に依存することのリスクなどを論理武装して説得にあたったりする必要があって、途中で面倒になりもういいやって気分にもなったりします。

一方でエンジニア畑の人であったとしても、生涯現役みたいなことを掲げているような人じゃない場合は、内製化に非協力的な立場であったりもします。

さらに上の立場の人から予算を抑えろとかうるさく言われる立場なのでトータルコストを見て判断しようとしているのはわかったりもするんですが、自分たちの現役の頃のシステム構築の現場というものが頭から離れず、オープンソースや無料で公開されているAPIとかをひどく懐疑的な目で見てたりもします。

人月換算でシステム構築の見積もりが中心だったりもするので、これを組み合わせれば数日でできますよって説明をしたところでその品質とかにひどく疑問を持ってたりしてあまり素直に受けれてくれなかったり。

内製化することは楽しいことだったりするものの、現状あまりそれを素直に実行できる環境というのは随分と少なくなったのかなと感じたりします。

自分はシステム部門として長年働いていたりしますけど、内製化が面倒になったと思うことはしばしばあります。

内製化は簡単になったのか

確かにひどく複雑な処理をするライブラリが無料で手に入り、おまけに組み込みも非常に簡単に、というようなものは多々あります。

ただし、内製化が簡単になったかどうかというのはまた別の話で、結局求められるシステム要件というのは変わってなかったりするわけですよね。

実装は簡単になったけど、システムを保守・運用していく中では相変わらず複雑なものを求められます。

それはセキュリティだったり、オープンソースを使うことでそのトラブル時の対応は自己責任で、といったことで生むは易しでも生んだ後の責任は付いてまわります。

難しい知識が無くても生み出せたものでも、それを保守していく中では生み出すとき以上の知識が必要になってくるわけです。

エンジニアの教育も兼ねてと寛大な環境ならいいにしても、そうではない場合はすぐに内製化のデメリットばかりに目を付け始められたりもします。

ライブラリや簡単なAPIが公開される時代になったからといってエンジニア自体に求められるレベルというものは決して変わってなかったりすると思います。

そして、内製化自体は簡単になったとしても、それ以上に安価で（場合によっては無料で）高度なサービスが提供されているような状況になっていたりもしていて、それは一から作る意味を見出せない状況も生み出したりもしてるんじゃないかなと思ったりもします。

マッシュアップなどで簡単に構築が出来たとしても、それはその範囲内でしか作れないものだったりもしますし、自己満足で作っても外部により良いものがあれば目の肥えたユーザーをだますこともできません。

なので、簡単な内製化で対応できる範囲って凄く限られたところにとどまるんじゃないかなとも思ったりもします。

それ以上のことは、とても「簡単」という範囲では対応できないようなことじゃないかなと。

ある程度経験をつんだエンジニアからしてみれば開発が効率化されたとか思ったりするんですけど、それって決して内製化自体が簡単になってエンジニアに求められるスキルレベルが下がっているということではないと思うわけです。

まとめ

内製化について否定的な部分も書いたりもしましたけど、基本的に私自身は内製化を進めたいと思っている側の人です。

やはり作る楽しみというものを覚えたりもしているので、それを他のエンジニアにも体感して欲しいと思いますし、オープンソースやライブラリで簡単に構築できる現状は、そのエンジニアとしての作る楽しさを体感するきっかけとしては凄くいい環境じゃないのかなと思ったりもしてます。

ただ、そういった状況になってたりもするもののそれを理解していない人も多くいるわけで、本当に内製化のメリットを感じて欲しいのは上で陣頭指揮をしているような人だよな、と思ったりするわけです。

目の前のコストやリスクだけを考慮して論理的に判断していって、競争力が低下したなんて嘆いているのを見てるとそれはエンジニアを育てる環境を作らなかったんだから当たり前のことなんじゃないのとも思うわけで、そういったエンジニアを育てる環境を作る一環で内製化というものも今一度きちんと天秤にかけて再評価してみるべきじゃないかなと思ったりします。

関連記事

部下ができたプログラマーのもどかしさ

「イエス」から始める

形骸化しやすい運用プロセスとその設計

規模の大きなプロジェクト運営で気をつけたいこと

プログラマがプログラミング以外にしていること

5年目のエンジニアと話してアドバイスしたこと

プログラミングが出来る人になるための熱意

何故プログラマーはシステムを作り直したくなるのか

運用の中で崩壊していくシステム

社員が利用するソフトウェアは統一すべきか

プログラミングが出来る人になるための熱意

プログラミングの出来る人と出来ない人の決定的な違い。 ＠ ワンヤグ

プログラミング自体に興味がもてないとプログラミングができないというのはよくわかる。

後はそこにどれだけの情熱を注げるかってことになってきたりすると思うんですが、世の中のプログラマーさんをみてたら、本当にプログラミングが大好きなんだなって思う人もいっぱいいます。

ただ、その情熱というのはプログラミングだけでなく、作る対象に注ぎ込むもんだったりするのかなと思う部分もあります。

サービスを作るのが好きか、プログラミングが好きか

プログラミングができないという人でも、何か自分でウェブサービスやソフトウェアを作ってみたいって思ってる人は結構いるんですけど、どうやって作ったらいいのかわからないと足踏みしているのを見ると、そのサービスやソフトウェアの骨子となるプログラミング自体には興味が無いんだろうなと思ったりもします。

ただ、本当にそのウェブサービスを作ってみたいのなら、プログラミング自体にも自然と興味が持てるとは思うわけです。

そこでの機能やインターフェースやデザインを構成している根本はプログラミングなので、それを制御する面白さというのもコードを書いていく中で味わえたりします。

もちろん適材適所があるので、何でもかんでも自分でやるというのは無理もあるでしょうし、単にサービスを作ってもそれをどう運営していくのか、ビジネスモデルを構築していくのかって方に秀でた人は無理にコードをかくことをせずに、優秀なプログラマーと分担して作っていく方が効率的でしょう。

多分、プログラミングの出来るか出来ないかってそのサービスやソフトウェアを作りたいって時にコードを覚えて書こう！と突き抜けられるかどうかってところなんじゃないかなぁと。

自分もプログラマーになりたいって思ったのは、（今じゃ違う業界ですけど）ゲーム自体を作りたいってところからスタートしてたりしますし、プログラマーになった人って何か強烈に作りたいものがあったんだろうと思います。

ただ、自分の場合は当初作りたいと思ってたものも作れずダラダラとプログラミングしている感じなので、並みのプログラマーとギークと呼ばれる人たちの違いって、単に設計書に落ちたものを作りますよというのか、自分自らがイメージするものを作り上げるかの違いにもなってくるんだろうと感じます。

作るサービスに情熱はあってもプログラミングに熱意は無くては良いものは作れません。

今じゃ出来合いのものを組み合わせたり、マッシュアップしたりして簡単に作れたりもするわけですけど、そういうものって既定の枠組みを超えることって出来ないわけですよね。

アイデア次第でその考え方はなかったわ、ってサービスもあったりしますけど自分オリジナルのものを作っていきたいとなると、それを生み出す技能を身につけなければならないわけで。

どうやってプログラミングを身につけるか

プログラミングが身近ではない人から見れば、それを覚えること自体は結構大変なことだとは思います。

自分も、非プログラマーな人にプログラミングを教えたことありますけど、どうにも理解してもらうことがなかなか難しかった記憶しかありません。自分が教え下手なのもあると思いますけど。

条件分岐や制御構造の書き方を教えても、何でそう動くのかがまったく理解できてない感じで、コンピュータ脳になってる人じゃないとイメージが掴みづらいんだなと思った記憶があります。

「駅にいきたい場合は右の道を、公園に行きたい場合は左の道を行く」というのも条件分岐も、自分という変数を表現した瞬間に大混乱して、その変数というもののイメージがまったくつかめてなかったりします。

配列を理解させるためによく箱に例えたりしますけど、ああいうのもわからない人からみれば箱自体が頭の中でプログラミングの中の配列とリンクしないんでしょう。

「Apple＝リンゴ」という変換と同じように、「配列のこのキーの値＝Apple」という変換が頭の中で即時に出来ない感じで。

ただ、条件分岐や制御構造などのプログラミングの基礎は慣れでもあり、そういうもんだと決め付けの意識で最初は流してしまってもいいんじゃないかと思います。

プログラミングを覚えるのは、そういう書き方を覚えるだけでなくて実際に自分が作ってみたいプログラムを動く形にすることに熱意を注いだ方が上達も早いですし。

そこで、面白いと感じてコードを書いていくうちに慣れていきますし、汚いコードでもこういう書き方もあるんだよと訂正されながら覚えていきます。

なので動いているプログラムを見せて、ここをこういう風に書き換えたらこんな動きに変わるんだよと具体的なイメージを見せながら覚えてもらった方が早いんじゃないかなと思ったりします。

それを自分が作りたい方向に変えていって、その作業が面白いと感じられるかどうかかなと。

で、繰り返しになりますがそのコードを書き続けたいって熱意がプログラミング出来る人と出来ない人を分け隔てることになるんだなと感じるわけです。

関連記事

エンジニアの情熱と暴走モード

プログラマがプログラミング以外にしていること

5年目のエンジニアと話してアドバイスしたこと

何でも屋であることの強みと危うさ

トラブル時のシステムエンジニアと非システムエンジニアの焦りの違い

何故プログラマーはシステムを作り直したくなるのか

システム屋が非システム屋と話すときに留意すること

運用の中で崩壊していくシステム

社内とネット上とで随分と変わってくる「優秀なエンジニア」の定義

管理職エンジニアが伸び悩む理由