Home > Archives > 2007-04

2007-04

Djangoで画像掲示板(みたいなもの)を作りました

嫁が洋裁関連のブログを書いているんですが、そこで他の人が作ったものをアップロードできる仕組みがほしいということで、Djangoを使って作った。
画像をアップするのに複雑なやり方をすると難しそうなので、画面遷移なしで画像をアップさせて簡単に使えるようにしたつもり。

NUI みんなの作品

ブログ本体はMovableType+PHPだけど、/sui/ディレクトリ配下でDjangoを動かした。

洋裁関連なので「じゃーアップして使ってみてください・・・」というのは難しいかもしれないけど、それほど気にならない速度で動いているのはわかるかな。

ちゃんとテストせずにオープンしちゃったからバグも結構残っていると思うけど、徐々に調整していこう。

で、まだ全く追ってないんだけど、問題があったので報告。

1.末尾スラッシュが無い場合にうまく動かない

まだちゃんと見ていないが、mod_rewriteの設定が関係していそう。

2.存在しないURLで、Internal Server Errorが返る

DjangoのDebugをFalseにしたらそうなった。
404エラー関連の設定なのか、django.cgiが404のときにうまくハンドリングできていないのか。
500が返るのはさすがにかっこ悪いので、あとで追ってみよう。

あと、やっぱり一番気になるのはどれくらいこのサービスを使ってもらえるかだな。
さすがに0件だと寂しい。。。
みなさんの周りで、バッグ作ったりしている人がいたら紹介してみてください。
それから面白いアイデアがあればそれも教えてください!

なぜDjangoを使い始めたか

比較の対象は以下の3つだった。
・web.py
・TurboGears
・Django

技術論というより気持ちの話っぽいけど、それぞれ触ってみた感想を書いてみる。

■web.py
ちまたの噂ではweb.pyという一つのファイルで動作とか書いてあったのに、ダウンロードしたらいくつもファイルが入っている。
多分バージョンアップしたんだろうし本質的にはそれほど変わらないのかもしれないけど、なんとなく保留。

■TurboGears
まずインストールして簡単なサンプルを作ってみる。
テストサーバーを立ち上げて、意外と簡単に動作したのでびっくりする。

次にApacheの後ろで動かそうとしてみる。
CherryPyを立ち上げずにmod_pythonとかで動かそうとするとうまくいかない。動かすためにはなにやら黒魔術的なものが必要そう。
CherryPyを立ち上げてmod_proxyでつないで動いた。

感じたのは、なんとなくしっくりこない。
確かにアプリケーションを作るのは楽そうだし、Ajaxとの連携もできる。MochiKitもいい感じ。
でも全体的に見通しが悪い気がする。
お前は言われたとおりに作ればいいんだよ的な印象。

そしてApache+mod_pythonだけで動かない(というか自分ができなかっただけかもしれないけど)も好みじゃない。
その辺の安い共用レンタルサーバーでは動かせないと思った。

■Django
まず驚いたのはドキュメントがしっかりしている。日本語ドキュメントも充実していて素晴らしい。(活動している方ありがとうございます。)

インストールして動かしてみる。普通にmod_pythonで簡単に動いた。

Ajax連携機能は無いものの、全体の見通しが良く黒魔術的なものも少ない。
Ajaxは適当に自分で実装すればいいやと割り切る。

確かにRuby on Rails的なフレームワークとはちょっと違うが、これくらいの温度感が嬉しい。見通しが良い分、自分でアプリケーションを作っている感覚が強いと思った。

■結論
結局Djangoが一番しっくりきた。自分にとってすごくわかりやすかったし。
誤解を招くかもしれないけど、Windowsで開発するよりもLinuxで開発したほうが分かりやすいというのと同じような感覚を覚えた。

Pythonを始めた理由

Pythonを始めた理由。
それはソースをみてきれいな感じがしたから。
この一言に尽きる。

比較にあがったのはPerlとRubyだけど、直感でPythonやってみようと思った。
Perlはあの記号モリモリな感じがどうにも好かなかった。ソースが読みにくくなりやすいという「噂」も気になった。
自分で書いてみてもなんかしっくりこないし。

RubyはPerlより好みっぽかったが、Pythonより記号が多そうな雰囲気とendがジャマに見えた。
ちょっと使ってみた感想だと、Pythonの方がシンプルな感じがしたのもRubyよりもPythonを選んだ理由。

あとはGoogleがPython使っているらしいというミーハー根性もかなり重要なファクターだったと思う。

みんなはどういう基準で言語を使い始めるのかなぁ?

SIerとかはマジメな比較とか評価とか好きそう。項目を立ててポイントつけちゃったりして。
そして、なぜか結局Javaが点数高くなっちゃうとか。

クリエイティブクラスとかいうのを甘えに使わないように

昨日は、全日本空手道連盟の公認段位を受審してきた。(ちなみに東京都です)
で、長い待ち時間を利用してこの本を読んでみた。

クリエイティブ・クラスの世紀
リチャード・フロリダ 井口 典夫
ダイヤモンド社 (2007/04/06)
売り上げランキング: 446

流し読みしただけだが、気づいたところを書いてみる。

クリエイティブクラスとはドラッカーの言うところの知識労働者とほぼ同じことを言っていると思うけど、すべての人がクリエイティブを持っているというところと、寛容性が大事だというところが本質的にちょっと新しいところなのかな。
まー、言い古されている話をうまく言い直しただけな気がするけど・・・。

寛容性が大事だというのはうなづける。

Googleなんかは保守・運用やサポートなどでもクリエイティブな人がいるからあれほど発展しているのだろう。
そして、その泥臭い部分にもクリエイティブな人たちが集まってくるのは、Googleの寛容さ(=新しいもの、新しい考え方を認めるということ)だといわれると納得する。

振り返って自分の身の回りを見てみる。

運用などの一般的に不人気の仕事をしている人たちが、自らクリエイティブであろうとしているだろうか。
いわれたものを作るだけだったり、決められた運用業務を淡々とこなすだけだったりという人たちはたくさんいるが、その中でクリエイティブを発揮しようとしている人たちが何人いるだろうか。

与えられたやり方で与えられたことをやるのが仕事だと思っている人がかなり多いと思う。
自分は本当はクリエイティブなことができるのに、現状が悪いんだと心の中で思いながら。

しかもひどいことは、一般的にクリエイティブと思われている企画などの業務に近い人たちでも、楽しようとするばかりで自らクリエイティブを発揮しようとするよりも先に、できない理由を探して現状のルーチン業務をこなそうとする人が多い。
そしてその人たちも、自分は本当はクリエイティブなことができるのに、現状が悪いんだと心の中で思っていたりする。

そこで気になるのは、すべての人がクリエイティブになりたいと思っているという前提だ。
普通にインタビューすれば、そりゃーみんなクリエイティブになりたいというだろう。
でも本心からそう思ってる?

実際にはクリエイティブであるためにはかなりのパワーがかかり、それに耐えられない人が多いはず。
パワーがかかるのは寛容性が足りないからかもしれないが、寛容性があると今度はかなりの人がそれに甘え始めてしまう。

新卒の学生が就職するときに、企画とか事業開発をやりたいと思う人が半分以上いるが、新しい課題に取り組みたいと思うのはごくわずかだというのが現実だ。
そういった学生の一部は夢見就職して、自分のやりたいことができない、こんなはずじゃなかったといって3年で会社を辞めてしまう。

格好つけてクリエイティブといいながら、実際の行動には結びつかないことが多いというのが本当のところだろう。
クリエイティブ=泥臭いことはやらないと思っている人までいそうだ。

寛容性を持つ社会になれば今よりはクリエイティブな人が増えるかもしれないが、それ以上に環境に甘えてなあなあになる人がもっともっと多くなると感じる。

本当はクリエイティブを発揮してほしいのに、細かな指示でその通りにしか動けないor動きたくない人に、お前もクリエイティブクラスにならなければならないと指導するのはどうしたらいいのだろう。

クリエイティブを発揮できるまでハードマネジメントをしながら駄目だしし続けるというのがひとつの手段だと思う。
「お前はなんでそれをやるのか?」
「なぜ考えて行動しないのか?」
「考えが浅いor甘いのはなぜなのか?」
「お前の価値はなんなのか?」
「お前は何のプロフェッショナルなのか?」

クリエイティブが存在できるための寛容性は持ちつつ、甘えてできない理由を探している人はきっちりマネジメントできる用にしなきゃいけないんだろうな。クリエイティブな人を認識して見合った給与を与えるというところまで含めて。
それにはマネージャーやリーダー自身が自分自身にも厳しくできる力が必要なんだと思う。

こういった本を読むたびに実際の現場での話と遠いなーと思わざるを得ない。
以下ではこんな話もされていた。時間の無駄だといわれたが、待ち時間の無駄な時間に読んだからまだ良しとしよう。
池田信夫 blog クリエイティブ・クラスの世紀

左の画像には、リンクを張ってない。こんな本を読むのは、金と時間の無駄だからだ。

クリエイティブな人材を増やしたいというなら、空中戦ではなく現場を見据えた話をしてほしい。上記の池田信夫blogのほうがよっぽど納得感がある。

そして自戒の念もこめて、現場はクリエイティブでありたいというのを甘えの言葉に使わないように。

あ、そういえば公認段位を受審した感想は、やっぱり稽古不足。
形もちょっとぶれてるし、組手も力みすぎだし。
今回は弐段だったけど、これから先に進もうと思うともう少し自分の稽古をしないとなー。

PHPは本当にダメな言語なの?

  • 2007-04-20 (金)
  • PHP

恐れ多くもこのエントリーに反応してみる。
Matzにっき(2007-04-13)

とはいえ、実際に「喜んで」PHPを使っている人はそれなりにいるわけで(「しかたなく」使っている人も大勢知ってるけど)、そういう人たちはまた別の理由や動機があるのだろうか。それとも「現状に満足しちゃってる」とか、「新しい言語を学ぶくらいだったら、非効率な方がマシ」ということなんだろうか。時として「知らないこと」は強力な動機となるわけで。

さらに元ネタはこれ

指摘されているPHPを使うネガティブな理由はごもっともだが・・・
ここで指摘している「PHPを使っている人」の定義がフレームワーク作者みたいな優秀なプログラマとか、複雑なサイトを開発している人を指しているかもしれないが、あえて一般人にとってPHPのいいところを個人的な感想でで3つに絞ってあげてみる。(使っている人が多いなどという言語の特性以外の理由はあえて省いた)
なぜなら一般人が使いやすいものが一番普及するのは当たり前だと思うし。

1.デフォルトでちょっとしたWeb開発に必要なものが揃っている
大半は簡単なスクリプトをHTMLに埋め込めればいいという開発だって多い。特にEUCっぽい環境など。
そこで必要最低限の(というかWEBに特化したマニアックな)ライブラリがほとんど揃っているのは強い。
それ以上のことをやりたいと思わないのだから、それ以上の言語は必要ない。

2.includeの使い勝手の高さ
普通にHTMLを作っているときに、ちょっとここだけ動的にしたいというニーズがあったときに、適当なPHPスクリプトをincludeしたら実現できる。
これは実はすばらしいと思う。(しかもこれを言語としてサポートしている)
テンプレート言語としてPHPを見ると優れていると感じるだろう。(※1)

2’.Movabletypeとの相性の良さ
これは個人的な理由だが見逃せない。
HTMLを吐き出す仕組みにちょっと動的ページを自作してアドオンするときの使い勝手は素晴らしいものがあると思う。
ほとんど2と同じことを言ってますね。

3.余計な事ができない自由度の無さ
自由度が無い分、下手なことをされることも少ないので助かる。
特にレベルの高くないプログラマをたくさん集めて開発するときなんかには、PHPのほうが安心感がありそう。(※2)

※1
そもそもPythonとかRubyとかPerlと比べるから分けわからなくなる。
土俵が違うでしょ。

※2
この辺はJavaを選択する理由と似ている。
もちろん良い悪いの議論はあるけど、現在の日本のSIerでマネジメントもやらなきゃいけない立場からすると、PHPのほうがプロジェクトの計算をしやすい。
いや、それだけじゃだめなのは理解してますよ。。。

Django newformsのImageFieldを使う

画像アップロードを作りたくて、Django newformsのImageFieldを使ってみた。
ファイル名周りでいろいろ問題がありそうだけど、ユーザーがアップしたファイル名はどうせ使わない仕様のつもりだったので、まーいいかと思って試した。
どうやらリリースには含まれていないので、ここからパッチを入手。
#3297 (newforms: Implement FileField and ImageField) - Django Code - Trac

現時点で最新のパッチを使った。

djangoと同じディレクトリ(ここでは$HOME/local/lib/python/site-package)にパッチファイルを置いて以下のコマンドを実行

patch -p0 < 4921-newforms-file-imagefield.diff

フォームの定義はこんな感じ

from django import newforms as forms
class ImageForm(forms.Form):
image = forms.fields.ImageField(widget=forms.FileInput(), required=True)

次に実際にファイルを読み込んでサムネイルを保存するところのサンプル。
これを少し改造していけばそれなりに動くものになるかな。
(微妙に省略していますが雰囲気はこんな感じ)

from cStringIO import StringIO
from PIL import Image
 
small_size = 200, 200
filepath = ‘/tmp/hoge/fuga.jpg’
 
post_data = request.POST or None
post_data.update(request.FILES) # 注意:ファイル情報はPOSTじゃなくってFILEに入るよ
 
form = ImageForm(post_data or None)
 
if form.is_valid():
form_data = form.clean_data
image = form_data['image']['content']
 
im_thumb = Image.open(StringIO(image))
im_thumb.thumbnail(small_size)
im_thumb.save(filepath)
[/code]

[補足]さくらインターネット、CGIでDjangoを動かす

さくらインターネット、CGIでDjangoを動かす
上記のおとといのエントリーでDjangoを動かす話をしたが、大事なことを忘れてた。

Djangoをインストールして普通に動かそうとすると、mysql接続で以下のエラーが出た。
※ちなみに、動かしているのはリリース版のバージョン0.96。

CODE:
  1. File "build/bdist.freebsd-4.10-RELEASE-p24r1-i386/egg/MySQLdb/connections.py", line 198, in __init__
  2. File "build/bdist.freebsd-4.10-RELEASE-p24r1-i386/egg/MySQLdb/connections.py", line 280, in set_character_set
  3. _mysql_exceptions.NotSupportedError: server is too old to set charset

仕方が無いので以下のDjangoのソースをちょっといじって無理やり動かした。
いじったのはこのファイル。
$HOME/local/lib/python2.4/site-packages/django/db/backends/mysql/base.py

83行目に「'charset': 'utf8',」という行があるが、これをコメントアウトする。
普通にutf-8で動かしているなら、これでも問題ないはず。

うーん、この辺がイレギュラーであまりよろしくないけど、他に良い解決方法を知っていたら教えてください。

2007/09/25追記
さらに補足です。
さくらインターネットでDjango、再び

SIerの技術力とイノベーションのジレンマ

F's Garage:rubyとかPHPとかPerlとか。
void GraphicWizardsLair( void ); // AmazonはSIerな方面もWeb2.0も強いのに、なぜかSIer分野はblog界隈で注目されないよね
を読んで、話がずれてきているかもしれないけど最近良く思うことを書いてみる。

確かにSIer方面な技術って表に出てこないなー。
それどころか、そもそも技術が無いと思われてたり、職業プログラマは趣味プログラマに負けてるといった話も出てくるし。

話が出てこないのは、NDAの問題とかオープンにして行く気がないという意識の問題とかも確かにある。
それに加えてSIerの技術の真価は裏側の仕組みで、触れる機会そのものも一般的には少ないからっていうのもあるんじゃないかな。

例えば、ミッションクリティカルなシステムのそれなりに大規模のシステムのインフラを構築するとか、安全に運用をまわすノウハウとか、そういった技術はSIerは強いと思う。(もちろんWeb2.0といわれる企業でも、一部の大手はSIer以上に裏側にそういうのに長けた人たちがいるはずだけど)

複雑な業務フローを分析してシステムのグランドデザインをできる人も確かにいる。

こういう技術は比較的小さなシステムを相手に仕事している人や趣味プログラマが触れることは少ないし、動くものを見て「すげー」という機会も少ない。
つまり、話題にしにくい上に関係の深い人も少ないし、派手さが無くって面白くない。

そして、SIerの中の人はみんなそういったものに触れるかというと、そんなことは無い。
特にフロントエンドのアプリケーション開発をしている「SE」と呼ばれる人は、期限通りに要求されたものを作る管理技術は学ぶけど要素技術はそれほどできなくても仕事はできることが意外と多い。

また、プロジェクト規模が大きくなればなるほど歯車として動くようになるので、システム全体を把握できなくて偏った知識になってしまうこともある。

そうなると、Webに公開するプログラムを作ったり、レンタルサーバーを借りて設定したりといった技術はそのへんの趣味プログラマに負けてしまう。

この辺の話が誇張されながら広まるので、SIer(or 職業プログラマ)の技術力に疑問符がつくのだと思う。

ただ、そのアプリケーション開発の進め方のせいで、設計がまずいものができたり、要件を柔軟に変更できなくなったり、細かい話もすぐに契約・スケジュール・お金の話になったり、というのがあるのは確か。
そして、チープな開発が徐々にSIerの足元に迫っている気がする。

でも、今の仕事のやり方でお金が儲かっていて、Web2.0的なチープな開発に切り替えられず、今ある技術を武器にしてミッションクリティカルな大規模開発にばかり目が行ってしまう・・・、というのがSIerのイノベーションのジレンマなんだよな。

画面遷移なしでファイルアップロードする方法

画面遷移をせずに画像ファイルをアップロードさせたいと思った。
で、普通にAjaxでできるだろうと思ってコードを書き始めてハッと気付いた。
multipartで送るためにファイルを読もうとしても、Javascriptからじゃローカルのファイル読めないじゃん。(当たり前ですが、セキュリティのためにできなくなっています)

ということで以下のサイトにあるようにiframeを使う方法で実装した。
Rubyist - yamazのRails日記 - Ajaxっぽく画面遷移なしでファイルアップロードしたい! Railsで画面遷移なしでファイルアップロードを行うから引用

formタグにはtarget属性というのがあって,リクエストを処理するブラウザのウインドウ名が指定できます.
Aタグのtarget="_new"とかで新しいウィンドウを開くみたいなノリだ.
またそのターゲットはname指定されたiframeでもOKなので,iframe内で処理をすることによって遷移なしのファイルアップロードが実現できている.
今回の例では'frame'というname属性をもったダミーIframeタグを準備しているので,これがブラウザ上で見えて嫌な人はstyle="display:none;"などで隠すとよい.

RoRの話だとちょっと分かりにくい(単純に知らないともいう)ところがあったので、PHPで簡単なサンプルを作ってみた。
画像をアップロードすると、phpファイルが置かれているのと同じディレクトリに画像を保存して、フォームの下に画像が表示される(はず)。
※画像やファイル名のチェック、エラー処理などは全く考慮してないので注意!

upload_test.html
⇒ iframeのstyle=display:none;について注意が必要、追記参照

CODE:
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  5.     <title>画面遷移なしでファイル(画像)アップロード</title>
  6. </head>
  7. <body>
  8.     <form action="./upload.php" method="post" enctype="multipart/form-data" target="upload_frame">
  9.         <input type="hidden" name="max_file_size" value="1000000" />
  10.         <input type="file" name="upload_image" />
  11.         <input type="submit" value="画像アップロード" />
  12.     </form>
  13.     <div id="container"></div>
  14.     <iframe name="upload_frame" style="display:none;"></iframe>
  15. </body>
  16. </html>

upload.php

CODE:
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  5.     <title>画像アップロード(iframe内)</title>
  6. </head>
  7. <body>
  8. <?php
  9.     $upload_dir = './';
  10.     $filename = $_FILES['upload_image']['name'];
  11.     move_uploaded_file($_FILES['upload_image']['tmp_name'], $upload_dir.$filename);
  12. ?>
  13. <script type="text/javascript"><!--
  14.     var container = parent.document.getElementById('container');
  15.     image = parent.document.createElement('img');
  16.     image.src = './<?php print($filename);?>';
  17.     container.appendChild(image);
  18. //--></script>
  19. </body>
  20. </html>

ちなみにimgタグをcreateElementする際にparentを付け忘れると、Firefoxでは動くがIEでは動かないので注意。
(ちゃんと実装するときは親側に関数を用意してキックするほうがよいと思う)

これでファイルアップロードの時も、もう少しjavascriptをごにょごにょするといろんなことができそう。

※追記 2007/04/17 15:20
アップした直後によくまとまったサイトを見つけた。
画面遷移なしでファイルアップロードする方法 と Safariの注意点 (groundwalker.com)
どうやらSafariだとiframeのstyleにdisplay:none;を指定してはダメらしい。

iframe の style に display:none; を指定するサンプルコードを見かけるが Safari の場合 display:none; だとファイルアップロードのスクリプトが新しいウインドウで走ってしまうので注意。

気をつけなければ。

※追記 2007/07/18
このままでは、自分でアプリケーションを作ったときに上手く使えなかったので補足エントリーを書いた。
補足 画面遷移なしでファイルアップロードする方法

この方法は、画像をアップロードした瞬間に即座にデータを確定するときにはそのまま使えるが、画像とコメントなどを同時に編集して、次の画面でデータ確認やデータ登録完了させようとすると問題がある。
戻る対応をしていないので、確認画面や完了画面から戻るボタンで戻ると、アップロードした画像が消えてしまうから。

さくらインターネット、CGIでDjangoを動かす

自宅サーバーにDjangoを入れてちょこちょこいじっていたが、httpd.confのMaxRequestsPerChildを1に設定してもそこそこ動いていた。
ということはCGIでも意外と動くんじゃないの?ということでさくらインターネットの共用サーバーに入れてみた。

参考にしたのは以下のサイト
sh1.2 pyblosxom : CGIでDjangoを動かす
oqreの日記 - さくらインターネットでDjango

まずは準備でDjangoとMySQLdbを"$HOME/local"にインストール。
Djangoのバージョンは0.96を入れたが、この辺はoqreさんの日記とほぼ同じ。

$HOME/localにインストールしたので環境変数に以下を追加

setenv PYTHONPATH $HOME/local/lib/python:$HOME/local/lib/python/site-packages
setenv PATH $HOME/local/bin:$PATH
setenv LD_LIBRARY_PATH $HOME/local/lib

次にsh1.2 pyblosxomさんの情報を参考に以下のサイトからdjango.cgiを取得。
#2407 ([patch] CGI Support for django) - Django Code - Trac

32行目に以下の行を追加

sys.path.append('/home/XXX/local/lib/python')
sys.path.append('/home/XXX/local/lib/python/site-packages')

$HOME/srcにソースを置くことにしたので、95・97行目を以下に変更

sys.path.append("/home/XXX/src")
os.environ['DJANGO_SETTINGS_MODULE'] = 'XXX.settings'

django.cgi編集の最後は、環境変数の設定。
これが抜けているのに気付かなくって苦労した。
結局1行目の#!部分で渡すことにした。
参考:「さくらのレンタルサーバ」で Python外部モジュールを使う

#!/usr/bin/env PYTHONPATH=/home/XXX/local/lib/python:/home/XXX/local/lib/python/site-packages python

django.cgiは、最終的に(※)"/django.cgi"でアクセスできる場所(ルートディレクトリ)に置いた。

次はmod_rewriteの設定。
今回は都合により、特定ディレクトリ配下でDjangoを動かすように設定したためこんな感じにしてみた。
実はここではまったんだけどそれは後で。(※)

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^XXX/(.*)$ /django.cgi/$1 [QSA,L]

これでDjangoが動いた。
簡単なアプリケーションを作るつもりなので、動くようになったら公開します。
これであまりストレスを感じないスピードで動いてくれたら、ちょっとしたサイトを作るのに手軽にDjangoが使えそうだな。

追記 2007/04/18
このまま動かしたらmysql接続でエラーが出るので以下のエントリーで補足を書いた。
[補足]さくらインターネット、CGIでDjangoを動かす

※mod_rewriteの設定

まず最終的な環境はこんな感じになった
・ドメイン:xxx.example.com
・エイリアス設定したディレクトリ:$HOME/www/xxx/
・django.cgi:$HOME/www/django.cgi
・.htaccess:$HOME/www/.htaccess

最初にはまったのは、.htaccessとdjango.cgiを特定ディレクトリ配下に置いたら想定どおりに動かなかったこと。
$HOME/www/xxx/yyy/.htaccess ⇒ $HOME/www/xxx/.htaccess
$HOME/www/xxx/yyy/django.cgi ⇒ $HOME/www/xxx/django.cgi
上記のように変更。

次にさくらインターネットのmod_rewriteでは以下の設定では動かなかった。

RewriteRule ^/XXX/(.*)$ /django.cgi/$1 [QSA,L]

ルートディレクトリの/を除けば動くようだけどなぜだか分かりません・・・。
サブドメイン+Aliasを使ってるけど関係ないよなー。

この二つが重なって結構悩んでしまいました。。。

Home > Archives > 2007-04

Return to page top