きのふよりけふ、けふよりあした

tracとsvnの連携についてメモ。

これやったら何ができるかって言うと、
tracでリポジトリブラウザを参照できることと、
subversionのコミットログに特定の文字列を含めるとチケットに連携できる。


参考URL
http://blog.livedoor.jp/leaf_hiro/archives/51610036.html
http://d.hatena.ne.jp/milkaz/20110513


1.trac-admin /var/www/trac/project/ permission add username TRAC_ADMIN
で管理ユーザへ昇格

僕はBASIC認証を利用していたのでusernameにはBASIC認証のアカウント。


2.管理ユーザでtracのwebインタフェースから連携リポジトリ設定
名称 は任意で後で使う
種別 はSVN
ディレクトリ はSVNサーバ上のパス /var/www/svn/repo1 とかね。


3.trac-admin /var/www/trac/project repository resync {2の名称}
で現在のリビジョンまで trac の project と手動で連携


4./XXX/YYY/svn/ZZZ/hooks でスクリプトを設定
http://server-helper.doorblog.jp/archives/3409060.html

vi /var/www/svn/repo1/hooks/post-commit
DIR_PATH="/data/trac/sample-trac "
/usr/bin/trac-admin $DIR_PATH changeset added "$1" "$2"


5.TracCoreに組み込まれているCommitTicketUpdater, CommitticketReferenceMacro をプラグイン有効にする
Tracは連携を受けて、対応するリポジトリ名のリポジトリのリビジョン番号を検索し、そのコメント内に書かれているコマンド（refsとか）を判断して実行

TracWebインタフェースに管理者でログインする。
管理＞プラグイン＞Trac x.x.x を開く
下の方の tracopt.ticket.commit_updater.* にある、CommitTicketReferenceMacro, CommitTicketUpdater にチェックを入れ、「変更を適用」


これでsubversionのcommitがあればtracへ通知されるようになりました。

設定完了。

subversionにcommitするときは次のようなコマンドでtracのチケットと連携できる。

refs #nn
close #nn
fix #nn

コマンド名は複数の書き方ができ、関連付けるコマンドはreferences、refs、addresses、re、seeのいずれかで指定する。筆者の場合はよく「refs」を使っている。また、チケットを閉じるコマンドはclose、closed、closes、fix、fixed、fixesのいずれかで指定する。こちらは筆者の場合「fixed」を使っている。
チケット番号の指定には、「#チケット番号」か「ticket:チケット番号」という書式を用いる。例えばチケット1番を指定する場合には、「#1」か「ticket:1」のようになる。
同時に複数のチケットを指定したい場合には「,（カンマ）」やand、&といった文字で区切って指定する。例えば、コミットするソースがチケット5番と7番に関係する場合、コミットメッセージに「refs #5, #7」と書く。 次のページ


■trac連携でfix #nn などのときにcloseじゃなくしたい
vi /usr/local/lib/python2.6/dist-packages/Trac-0.12.2.ja1-py2.6.egg/tracopt/ticket/commit_updater.py
※/usr/lib/python2.4/site-packages/Trac-0.12.2.ja1-py2.4.egg/tracopt/ticket/commit_updater.py

　　def cmd_close(self, ticket, changeset, perm):

　　　　if not self.check_perms or 'TICKET_MODIFY' in perm:

　　　　　　ticket['status'] = 'resolved'　　　　　　　　　<== ここ

　　　　　　if not ticket['owner']:

　　　　　　　　ticket['owner'] = changeset.author

■tracのチケット削除
http://d.hatena.ne.jp/greennoah/20090310/1236692727
trac-admin /var/www/trac/project/ ticket remove 42

---

環境や設定によって違うっぽいのでよくわからんけど、もし困ったときの備忘録。

win mergeで2つのディレクトリ比較をするとき、
2つのディレクトリを同時にドロップしてしまうとサブディレクトリなどが展開しない。

1つずつディレクトリをドロップしていって
一度ポップアップ経由で比較をするとディレクトリすべてが展開されていて比較がしやすい。



ポップアップっていうのはこんな感じの。

でも、今改めてやってみたら大丈夫だった。

まあダメだったら試してみるってことで。

---

■はじめに

どうも、Webアプリケーションを作っているエンジニアです。
なんて言っていましたが、サーバのこと全然わかりません。
わからないので調べてみたのですがやっぱりわかりません。
何がわかってて、何が分からないのかを明確にするために
誤った情報が混ざることを覚悟してまとめてみます。
有識者の方、間違いや補足知識あればご指摘頂ければ幸いです。

■そもそもWebサーバって？

http://ja.wikipedia.org/wiki/Web%E3%82%B5%E3%83%BC%E3%83%90

Webサーバ（ウェブサーバ）は、HTTPに則り、クライアントソフトウェアのウェブブラウザに対して、HTMLやオブジェクト（画像など）の表示を提供するサービスプログラム及び、そのサービスが動作するサーバコンピュータを指す。 広義には、クライアントソフトウェアとHTTPによる通信を行うプログラム及びコンピュータ。

まあそれはわかっているつもり。
DNSとかTCP/IPとかインフラ的な話もあるけれど、
それはまた別の機会に。

で、

また、HTMLドキュメントに各種処理を組み込み、CGIスクリプトやJava Servlet（サーバ側で実行されるJavaプログラム）と呼ばれるWeb画面に連動した動的処理を行う事が可能である。CGI処理においてはPerl・Ruby・PHPなどのスクリプト言語によって開発されることが多い。
Java Servletにおいては、Javaによる動的処理の負荷を分散するため、Java Servletを処理する機能を別サーバに切り出し、Webアプリケーションサーバとして、垂直分散（スケールアウト）する事も一般化している。

というのがあって、CGIとJava Servletってどう違うの？ってことが気になる。
昔から気になってちょくちょく調べてはいたのですが、やっぱりまだはっきりとわからないんですよね。

Webサーバを自力で実装し始めたら理解できるようになるのかもしれませんね。

■CGIとJava Servletの違い

CGI
http://ja.wikipedia.org/wiki/Common_Gateway_Interface

Common Gateway Interface (コモン・ゲートウェイ・インタフェース、CGI)は、ウェブサーバ上でユーザプログラムを動作させるための仕組み。現存する多くのウェブサーバプログラムはCGIの機能を利用することができる。

これはOK。

CGIは環境変数や標準入出力の扱える実行環境からであればプログラミング言語の別を問わず幅広く利用できるが、実行速度やテキスト処理の容易さなどの兼ね合いによりPerlが使われることが多かった。近年では、Perlに加えてPython、Rubyなども広く使われている。

後半はOK。
前半は、つまりApache HTTP Serverならデーモンのhttpdがブラウザからのリクエストを受け取り、
環境変数や標準入出力を経由して、httpdデーモン内で新しくプロセス（インタプリタ）を起動して
そのプロセス内で環境変数や標準入出力の経由された情報を元に、
環境変数や標準入出力を経由してhttpdに処理を戻してブラウザにレスポンスする、ということ？なのかな。
どうだろう。

近年では、Webサーバのプロセスとしてインタプリタを常駐させておくことにより、CGIからプログラムを呼び出すオーバヘッドを減らし、パフォーマンスを向上させたJava Servletやmod_perl、mod_php、FastCGI、WSGIなどのインタフェース・実装も出現している。

前半はなんとなく、、、何となく分かる気がする。
CGIでは1リクエストあればそのたびに1プロセス起動していたのだがこれはオーバーヘッドが増えるため（問題点）やめて、
1プロセスを常に常駐させておいてリクエストがあればそのプロセスに処理を受け渡すということ？かな。
その方法のインタフェースや実装としてJava Servletやmod_perl、mod_php、FastCGI、WSGIなどがあるということかな。

じゃあJava Servletって？
http://ja.wikipedia.org/wiki/Java_Servlet

Java Servlet（ジャバ サーブレット）とは、サーバ上でウェブページなどを動的に生成したりデータ処理を行うために、Javaで作成されたプログラム及びその仕様である。単にサーブレットと呼ばれることが多い。Java EEの一機能という位置づけになっている。この機能を用いてショッピングサイトやオンラインバンキングなどをはじめとする多種多様な動的なWebサイトが構築されている。

って言葉尻だけはもうよく知ってる。概念として。
じゃあ具体的にどんな仕様？ってところが知るべきところなんだね、きっと。

同様の技術（すなわち対抗技術[要出典]）としてはPerlなどを用いたCGI、PHPプログラムのプロセスをApache HTTP Server上で動かすことができるmod_phpなどのモジュール、マイクロソフトが提供するASPなどがある。CGIがクライアントのリクエストのたびに新しいプロセスを起動するのに対して、サーブレットはメモリに常駐して、リクエストのたびにプロセスより軽量なスレッドを起動するので、効率がよい。また、サーブレットはJavaで書かれているのでさまざまなプラットフォームで使うことができる。

これはCGIの項目にも書かれていたこととほぼ同じだからわかる。
サーブレットはメモリに常駐して、リクエストのたびにプロセスより軽量なスレッドを起動する、
ってところがCGIの都度プロセス起動とは違うところ、なんだね。

サーブレットの実行環境（実行するためのソフトウェア）はWebコンテナ、またはサーブレットコンテナと呼ばれる。これらの言葉はあまり区別されずに使われることも多いが、純粋にサーブレットの処理を行うものをサーブレットコンテナと呼び、サーブレットコンテナを含みJSPやHTTPサーバとしての機能も含むものをWebコンテナと呼ぶ傾向がある。
Webコンテナとしては、Apache Tomcat, Jetty, BEA WebLogic Server, IBM WebSphere Application Server, Resin, JBossなどがある。

Java界隈でよく使う知ってる名前がいっぱい出てきた。
サーブレットコンテナ、であれば単独でWebサーバとしては動作せずにApache HTTP Server などと連携して動作させるもの、
なんだろう。
ん？このあたり、よく分からない。
Apache HTTP Serverと動作させるにはきっとApache HTTP Serverモジュールを使う。
それってApache HTTP Serverに依存しないんだろうか？
Apache HTTP Server以外でサーブレットコンテナを動作させるには、何がどう間を取り持つことに為るのだろう。

Webコンテナ、は単独でWebサーバとしても動作するということはOK。
でも、そんな環境で動作しているJava ServletをApache HTTP Serverから呼び出すってのはどういうことになるの？
それはなんて呼ぶの？
CGI？Java Servlet？
よく分からないな…。

ちょっとTomcatのWikipediaを見てみる。
http://ja.wikipedia.org/wiki/Apache_Tomcat

Tomcat 5.0から、Jasper2を含む。
Catalina - Servlet コンテナ
Coyote - HTTPサーバー
Jasper, Jasper2 - JavaServer Pages

これはよくわかる。

Webサーバとの連携 [編集]

Apache Tomcat は安定して動作し、静的コンテンツの HTTP サーバーとしても使えるので単体で用いることもできる。また、Tomcat 以外のHTTPサーバがHTTPリクエストを受け付け、必要に応じてサーブレットコンテナにリクエストを渡すという構成でHTTPサーバと連携させて用いることもできる。ただし、別 HTTP サーバーとコネクタ連携をすると、Advanced IO (Comet) など一部の機能が使えなくなる。例えば、Apache HTTP Server とコネクタモジュールを用いて連携を行う場合、Apache Tomcat 側では mod_jk をコネクタとして配布している。また、Apache 2.2以降は mod_jk とは別な方法として、mod_proxy_ajp モジュールを用いる方法もある。

これがわからない。
「Tomcat 以外のHTTPサーバがHTTPリクエストを受け付け、
必要に応じてサーブレットコンテナにリクエストを渡すという構成でHTTPサーバと連携させて用いることもできる」
ん？
これはどういったことをやっているんだ？
その間を仲介するのはどういうものがどういう仕組でどういう処理をしているんだ？
前述したWebコンテナのところの疑問と同質の疑問だろう。

■じゃあApache HTTP Serverモジュールってなんだ？

ちょびっと書きに書いている。
http://labs.yumemi.co.jp/labs/mod/apache_module.html

んーわからん。

これらのApacheモジュールはApacheにデフォルトで含まれるモジュールになります。
この中には、CGIスクリプトを実行するために必要な「cgi_module」や、「http://ドメイン名/」のように/で終わるURLの場合にindex.htmlにアクセスさせる「dir_module」、環境変数を制御する「env_module」など、当たり前のように使用している機能も含まれてます。
仮にApacheからこれらを削除すると簡単な掲示板プログラムも動かせません。

さらに、ApacheモジュールはApache内部の処理として動作するため、処理のために新たにプロセスの生成や通信を行なうことがありません。そのため、同じ処理を、phpやperlなどのプログラムで処理を行なう場合と、Apacheモジュールで行なう場合では、弊社作成の絵文字変換モジュールの場合、最大100倍以上の差(弊社比)がありました。

CGIはそもそもプロセスを何個も起動するからパフォーマンスが悪くなってしまう、それが問題だ、って理解しています。
「ApacheモジュールはApache内部の処理として動作するため、
処理のために新たにプロセスの生成や通信を行なうことがありません。」
というなら
CGIスクリプトを実行するために必要な「cgi_module」
は、CGIの定義がよくわからなくなります。
プロセス内で子プロセスを起動したほうが速い、ということでしょうか。
もうまったくわかりません。

他のものを見てみましょう。
mod_perl、mod_php、mod_pythonはApacheモジュールです。

Wikipediaに唯一リンクの存在するmod_python。
http://ja.wikipedia.org/wiki/Mod_python

mod_python は Python プログラミング言語を Apache HTTP Server に結合するためのモジュールである。mod_python は web サーバ上で Python スクリプトを実行するための手段として、Common Gateway Interface を置き換えることを目的としている。高速な実行速度、複数のセッション間をまたいだ情報の保持などが特長である。

うん、CGIを置き換えるためのもの、なんだね。それはわかる。
で、だ。
「mod_python は Python プログラミング言語を Apache HTTP Server に結合する」ってのは、どういうことなんだろう？
結合ってところがよくわからない。

通常の CGI の実行は、サーバ上のスクリプトにコネクションが張られるたびに新しいプロセスを開始する。小規模から中規模トラフィックのサイトではうまく動作するが、高トラフィックのサイトでは十分性能が出ない。FastCGI などの CGI の性能を改善する方法はあるが、対象の言語を web サーバ自体に埋め込む専用のモジュールを用いた方が簡単な場合が多い。mod_python はそのために設計されている。CGI のようにスクリプトの実行後プロセスが終了しないため、データベースのコネクションのような情報を永続的に持たせることが可能である。これによってスクリプト実行のオーバーヘッドを減少させることができる。

「対象の言語を web サーバ自体に埋め込む専用のモジュールを用いた方が簡単な場合が多い。mod_python はそのために設計されている。」
おお？
Apache HTTP Serverに対象の言語を埋め込む？？？
ソースをmakeし直すってこと？んなわけないよね。
どういうこと？
わかんない。

■Active Server Pagesはどうよ？

http://ja.wikipedia.org/wiki/Active_Server_Pages

Active Server Pages（アクティブサーバーページ、ASP）はマイクロソフトが開発したウェブページを動的に作成する技術である。
HTMLなどのマークアップ言語とVBScriptやJavaScriptなどのスクリプト言語を組み合わせることで成り立つ。ウェブページ間のデータのやりとりが容易であるため、電子商取引（インターネットを通じた通信販売）などで活用されている。同様の技術として、Javaサーブレット、JavaServer Pages (JSP)、PHPなどがある。
ASPを動作させるためのWebサーバはInternet Information Services (IIS) やPersonal Web Server (PWS) があり、IISは当初マイクロソフトのサーバ向けOS (Windows NT Server,Windows 2000 Server, Windows Server 2003) にのみ付属していたが、現在ではホーム/ビジネス向けOS (Windows XP Professional, Windows Vista)にも付属されている。PWSはWindows 95、Windows 98にインストールすることが出来る。またWindows Me以降PWSの更新は行われておらず、マイクロソフト製のWebサーバはIISに一本化されている。
ASPの後継技術としてASP.NETが開発された為、現在では新規システムの開発でASPが利用される事は減りつつあるが、企業のイントラサイトや、小規模な動的ページで用いられる場合もある。

？
だいたい知ってる。
スクリプト言語でやるってことね。
で、WebサーバとWebアプリケーションあたりは何をどうするの？ってところの記述はないのでもう参考にしない。

■ASP.NET

http://www.itmedia.co.jp/enterprise/0211/04/epn01_4.html

ASP.NETは、Windows 2000 Serverに付属するIIS 5.0に.NET Frameworkをインストールした環境、または、2003年に登場予定の.NET Serverで動作するものだ。次世代のWebアプリケーション開発環境である。

　ASP.NETでは、プログラムが.NET Frameworkという実行環境上で動作するのだ。.NET Frameworkは、JavaでいうJavaVMのようなものである。VB.NETやC#など、.NET環境をサポートするプログラミング言語で開発されたプログラムを実行する環境だ。

ASPとASP.NETの違いはよくわかりました。
でもWebサーバとWebアプリケーションまわりは不明なままです。

ASP.NETの場合はIISと連携して動作するため、IIS自身がコンテナ扱いになる。コンテナという概念はないのだ（強いていえば、IISで設定する仮想ディレクトリがコンテナとしての機能を果たす）。ASP.NETでは、開発したWebアプリケーションのプログラムを拡張子「.aspx」を持つファイル名としてIIS上に配置すれば実行される（もしくはコンパイル済みのバイナリファイルを拡張子.dllをもつファイルとして配置してもよい）。

むー…。
わからん。
WebサーバとWebアプリケーションまわりのことはあまり記述無いので気にしないでおこう。

この同じページ内に参考になりそうな記述が。

　CGI（Common Gateway Interface）は、Webサーバがクライアントからの要求を受け取った際、Webサーバ上でプログラムを読み込んでそのつど実行する形式を指す。CGIで動作するプログラムの開発環境としてよく使われるのが、PerlやPHPなどのスクリプト言語である。

　CGIは、個人レベルや小規模なWebアプリケーションの開発に使われることはあっても、業務レベルのWebアプリケーションを構築する場合に使われることは少ない。それはCGIの処理パフォーマンスが悪いからだ。ここで誤解していけないのが、スクリプト言語による実行がパフォーマンスに影響を与えるというわけではない点だ。問題なのはCGIの仕組みであり、スクリプト言語ではない。

　CGIでは、クライアントから要求を受け付けた際、クライアントごとに1つのプログラムを実行する。簡単に言えば、同時に1000人のユーザーがアクセスすれば同じプログラムがサーバ上で1000個実行される。同時に数万人のアクセスがあれば、数万個のプログラムが実行されることになり、サーバがリソース不足となるのは明らかだ。

　そのような理由から、多数のクライアントから要求を受ける必要がある場合、CGIを利用するのは適さない。多数のクライアント要求を受けるためには、プログラムを1つ（または数個）だけメモリに用意し、アクセスする要求数分のスレッド構成をする方法がよい。そうすれば、パフォーマンスが劇的に向上するのだ。

　たとえばApacheでは、PerlやPHPで記述されたプログラムをスレッドで実行させる方法として、mod_perlモジュールやmod_phpモジュールが用意されている。これらのモジュールを使えば、PerlやPHPで記述したプログラムであっても、J2EEや後述するASP.NETに匹敵するパフォーマンスを得ることが可能だ。

　実際、中規模のWebアプリケーションでは、mod_perlモジュールやmod_phpモジュールを用いて開発することも少なくない。

TIPS：厳密にいえば、mod_perlモジュールやmod_phpモジュールは、Apacheと同じメモリ空間内でプログラムを実行する仕組みだ。スレッドとは意味がやや異なる。

「多数のクライアントから要求を受ける必要がある場合、CGIを利用するのは適さない。多数のクライアント要求を受けるためには、プログラムを1つ（または数個）だけメモリに用意し、アクセスする要求数分のスレッド構成をする方法がよい。そうすれば、パフォーマンスが劇的に向上するのだ。」
これは理解している通りだね。
「mod_perlモジュールやmod_phpモジュールは、Apacheと同じメモリ空間内でプログラムを実行する仕組みだ。スレッドとは意味がやや異なる。」
同じメモリ空間内ってOSレベル？プロセスレベル？わかったようでわからない。

■FastCGIって？

http://ja.wikipedia.org/wiki/FastCGI

CGIは、ユーザーから要求がある度に、プロセスの生成と破棄が行われる。大量の要求があればその分だけプロセスの生成と破棄が実施され、この事がパフォーマンスの悪化に繋がっている。
FastCGIは、プロセスをメモリ上に永続化させることで、その起動と終了にかかる時間をカットし、結果としてプログラム動作速度の向上およびサーバ負荷の低下が可能となる。最初にプロセスが実行された段階で、そのプロセスはメモリ上に格納され、次の要求に対してはそのメモリに格納されたプロセスを実行する。

「FastCGIは、プロセスをメモリ上に永続化」
うお？？
これは今まで見たこと無い記述。
プロセスってインタプリタのことかな？
これをメモリ上に保持してて、Webサーバはリクエストを受け取ると
このメモリ上のプロセスに処理を渡してレスポンスをもらうってことなのかな？

■WSGY？？

http://ja.wikipedia.org/wiki/Web_Server_Gateway_Interface

Web Server Gateway Interface (WSGI; ウイスキー) は、WebサーバとWebアプリケーション（またはWebフレームワーク）を接続するための簡潔かつ統一されたインタフェース定義である。プログラミング言語Pythonで使われる。

歴史的に、Python に存在する多種のWebアプリケーションフレームワークは、新規のPythonユーザーにとって問題になっていた。というのも、Webフレームワークを選択することによって、使用できるWebサーバが制限されてしまったり、その逆の制限があったりしたためである。Pythonアプリケーションは、CGI, FastCGI, mod_python, さらにはWebサーバ独自のAPIを使ったもの、などのいずれかとして設計されることが多かった。
この問題を解決するためにWSGIが作られた。WSGIは、可搬性のあるWebアプリケーション開発の基盤を形成するために、WebサーバとWebアプリケーション（もしくはWebフレームワーク）を接続する簡潔かつ統一された低水準インタフェースを定めるものである。これにより、WSGIに対応したWebアプリケーション（またはWebフレームワーク）は、WSGIに対応した任意のWebサーバ上で実行できる。

統一されたインタフェースというのはわかる。
これは、Webアプリケーション（またはWebフレームワーク）側でCGI、FastCGI、mod_pythonなどのインタフェースの違いを
吸収して実際のロジックまわりを簡潔に、というわけではなくて、
WebサーバもWSGY準拠、WebアプリケーションもWSGY準拠、って感じなのかな。
Webサーバを作る人がまた面倒くさい仕様が増えたってだけじゃないの？
Perl Web Server Gateway Interface、Ruby Web Server Interface、SCGIとかも増えたわけだし。
って考えると理解がおかしい？？

あと以下の記述。

PSGI/Plack [編集]
Perlスクリプトは実行ファイル形式またはモジュール形式を用いてウェブアプリケーションとして実行することができる。実行ファイル形式はCGI、FastCGI、SpeedyCGI、モジュール形式はmod_perl、ISAPIなどがある。このうちCGIが主な実行方法として知られているが、実行のたびにプロセスの読込・破棄を行っているため、オーバーヘッドが大きい。そのため、多くのアクセスを処理しなければならないウェブアプリケーションでは、パフォーマンスが悪くなることがある。一方、FastCGI、SpeedyCGI、mod_perlなどの環境では、プロセスをメモリ上に永続的に置くことによりプロセスの読込・破棄の作業を省き、高速化を図っている。
上記の実行環境はそれぞれインターフェイスが異なるため、ウェブアプリケーションフレームワークごとに差異を吸収するコードが繰り返し再発明されていた。この問題を解決すべく、宮川達彦氏主導の元、WSGIやRackにインスパイアされたPSGIというウェブアプリケーション フレームワーク用の規格が打ち出された[3]。また、同時にPSGIのリファレンス実装のPlackも発表された 。これにより、具体的な実行環境を意識することなくウェブアプリケーションを作成できるようになった。2010年現在では、ほとんどのPerl製ウェブアプリケーションフレームワークがPSGIに対応している。

「FastCGI、SpeedyCGI、mod_perlなどの環境では、
プロセスをメモリ上に永続的に置くことによりプロセスの読込・破棄の作業を省き、高速化を図っている。
上記の実行環境はそれぞれインターフェイスが異なるため、
ウェブアプリケーションフレームワークごとに差異を吸収するコードが繰り返し再発明されていた。
この問題を解決すべく」
ってのは、WebサーバからWebアプリケーションを呼び出す種類によって
インタフェースが異なるという理解が正しいことを後押している。
だとすると、Webアプリケーションだけでこの差異を吸収するだけじゃダメだったのかな？
やっぱり理解がおかしい？

■で、もともとこの話は…

ここまで散々悩みぬいてきたわけだけれど、
それはDjangoを利用した開発をしていて
「なんで開発サーバをインストールも設定もしてないのにブラウザから
http://127.0.0.1:8000/ でアクセスして動いているんだ？って思ったところから。

WikipediaのDjangoの項目は見てもわからなかった。
http://ja.wikipedia.org/wiki/Django

Django（ジャンゴ）は、Pythonで実装されたWebアプリケーションフレームワーク。 model-view-controller デザインパターンに緩やかに従う。 もともとはローレンス (カンザス州)にある World Company[1]のために、ニュース系のサイトを管理する目的で開発され、2005年7月に BSD License で公式にリリースされた。フレームワークはバンド gypsy jazz のギタリスト ジャンゴ・ラインハルト にちなんで命名された。
Django の第一の目的は、複雑で、データベース主体の Web サイトの構築を簡単にすることである。Django はコンポーネントの再利用性と'pluggability'、素早い開発、DRY (Don't Repeat Yourself)の原則に力点を置いている。ファイルやデータのモデルにいたるまで、Python が一貫して用いられている。
Django はまた、動的に生成され、データモデルの定義を通じて完全に構成することができる、データベース管理 CRUD インターフェイスをオプションで提供する。

だけどここに書いていた。
http://www.ibm.com/developerworks/jp/opensource/library/os-django/

Django アプリケーションをデプロイするための準備
これまでの説明でおわかりのように、Django フレームワークには便利なことに、Django アプリケーションをデバッグおよびテストするのに理想的な開発サーバーが組み込まれています。けれども残念ながら、このサーバーはローカル環境で実行するためだけに設計されているため、多くのユーザーが同時に使用する本番 Web アプリケーションには耐えられません。このことから、Django は Apache やlighttpd などの本番クラスの Web サーバーにデプロイする必要があります。これから、アプリケーションを本番環境で使えるようにするために必要なステップを検討した後、Django アプリケーションに対応するように Web サーバーを準備するためには何が必要かについて説明します。

これはOK。
まあ開発サーバがリクエストを受けてDjangoを利用しているpythonアプリとどうやって
連携しているか知りたいところだけれども。

WikipediaのDjangoの方に戻って以下の記述。

Django は Apache 2 で mod_python を使って、あるいは任意の WSGI 準拠のウェブサーバで動作させることができる。 Django は FastCGI サーバを起動することができ、FastCGI をサポートする任意のウェブサーバのバックエンドで使用することができる。

Django が mod_python もしくは WSGI準拠のWebサーバで動作しますってことはOK。
Django は FastCGIサーバをきどうすることができ…ん？全然わかりません。
FastCGIをサポートする任意のウェブサーバのバックエンドで使用することができる…ってのはなんとなくわかる。

■さいごに

とまあ、こんな調子で全然サーバのことわかりません。
何か読んだらこのあたりがすっきりする本とかあるのか。
誰かおしえて下さい。

〆

---

この前、チェコ、すごい雪積もっていましたね。
大寒波で死傷者が大勢出るほど…。
大丈夫なのでしょうか。

そんなチェコにあるjetbrainsの各IDEならの違いについてメモ。

どれを購入しようと迷って失敗しました…。

webstorm買ったのですが、intellij ultimateほしいです。

春のセールあるか知らないですが、毎年春とか冬とかやってるので待ってみます。

■intellij idea ultimate と community の違い

http://www.jetbrains.com/idea/features/editions_comparison_matrix.html

もちろんcommunityは無料。

あ、あとデフォルトでカーソルがうざいことになってるので下記を参照してください。

intellij IDEAのフリーカーソルを止める

keyword : caret, cursor

■製品間の違い

製品間での違いは下記が非常に参考になります。
IntelliJとAppCode(CIDR)、でもってその他(WebStorm/PhpStorm/PyCharm/RubyMine)の話

IDEAと他の製品のプラグインを比較してみた

java, python, ruby, php をいずれか一つしか絶対使わないなら細かい製品エディション買うといいかもしれないです。

どれも使いそうであればultimate買っとくといいかもです。

ただし、javaだけで言うとcommunityでアプリケーションサーバが対応してないからそれだけのためにultimate買うというのならば、eclipseかnet beansにしたほうが良いと思います。

よほどitellij idea のUIが好きなら別ですが…。

---

2012/01/30 22:59:54 追記
自分で後から読み返して、「えっ？」てなる記事は品質が低いですね…。
備忘録で書いたつもりなのに。
下記の方の記事がとても参考になります。
ちょっと手直しします。
http://d.hatena.ne.jp/itouhiro/20111005

前に書いたコチラの記事でegitを使ってgithubにプッシュするまでを書きました。
そのあともう一度同じ手順でやったけれど、うまくできませんでした。
ssh周りがどうにもこうにも…。
eclipseからsubversiveと同じようなインタフェースで使えて良かったのですが。

というわけで、使いやすさ云々よりもgithubで公開できることが第一なので、
TortoiseGitを使ってみることにしました。
何もわからない状態なのでとりあえずメモ。

やりたいことはすでに存在するeclipse上のプロジェクトをgithubで公開することです。

１．TortoiseGitをインストール
http://code.google.com/p/tortoisegit/からdlしてインストール
ここを参考に。http://sourceforge.jp/magazine/09/06/19/0340248
これはさほど問題ないと思います。

２．プロジェクトディレクトリ下まで移動してgit create repository here...
例えばd:\eclipse\workspace\project ディレクトリまで移動する。
ここで右クリックしてgit create repository here...をする。

2012/01/30 23:01:09　追記
上記ではうまくいきませんでした。
なので、上記例をとると、d:\eclipse\workspace ディレクトリまで移動して
projectフォルダを選択して右クリックしてgit create repository here...をします。




３．githubで公開したいファイルをaddする
ディレクトリから一気に！したつもりがなんかうまいことできていないファイルがあったりして、
信じられないですがディレクトリ探っていってファイルを複数選択してadd　add　していきました。
ignoreにいくつか登録したからそのせいで外されたのかもしれません。
まあよくわかってませんが、一個ずつ選択していけば間違い無いです。
twitterやfacebookのoauthキーとかをごりっと書いていたりしたら気をつけてください。



４．commitする
addしたファイルをごりっとコミットします。





５．githubでリポジトリを作る
リポジトリ作ったら表示される画面に「Next steps:」ってのがあり、
「git remote add origin [email protected]:user/project.git」みたいないのがあるので
origin 以降をコピーしておく。
リポジトリはこちらから作成します。
https://github.com/repositories/new



６．SSHの公開鍵と秘密鍵を作る
C:\Program Files\TortoiseGit\bin\puttygen.exe　でGenerateで鍵を生成する。
Save public key で公開鍵を保存し、Save private key で秘密鍵を保存しておく。
保存先は適当でよい。
一般的には「C:\Users\isann\.ssh\privatekey.ppk」こんな感じのユーザホームディレクトリの隠しフォルダ.ssh内。
これはLinuxでも同じ感じです。

次に、puttygenのKeyエリアの文字をコピーし、これをGithubのhttps://github.com/account/sshで公開鍵として登録。

そのあと、C:\Program Files\TortoiseGit\bin\pageant.exeを起動して常駐アプリで右クリックAdd Keyを選択し、先程保存した秘密鍵（private key）を選択する。







７．pushする
こんな感じ。



リモートURLは５でコピーしたもの。

これで公開できます。

ソースを変更したときはディレクトリルートで右クリック->Git Sync...で
同期化して変更を操作して（ローカルリポジトリに）コミットする。

そのあとでpushする。

ひとまずこれで。。。
すげー使いにくいな…。

---