TurboGearsなblogにFCKEditorがついた模様。
われらがmopemopeさん作のblogツールはreStructuredText入力なので、FCKEditorは不要（というか無意味）です。
そこで自作（駄作）のblogツールで頑張って対抗。。SafariでもWYSIWYG（ただしCSSがいまいち）だっ。うっ、Safariだと一部のボタンが消えていて画像とかリンクとかができない・・・だめじゃん。
http://www.everes.net/images/wysiwyg.png

というか、TurboGears製ブログツールとDjango製ブログツールのソースコードが閲覧可能ですね（こまい機能等違うでしょうが）。
TurboGears(lirisさん作)
Django(mopemopeさん作)

ちなみに、メーリングリストも揃い。
TurboGears-ja:  http://groups.google.com/group/turbogears-ja/
Django-ja: http://groups.google.com/group/django-ja/

Django非公式日本コミュニティ「Djangoと日本の仲間たち」のWebサイトがオープンしました。

• http://www.djangoproject.jp/

同時にいままでサイト準備のためにクローズで運営してきたメーリングリストもオープンになりました。

• http://groups.google.com/group/django-ja/

「Djangoと日本の仲間たち」のWebサイトはDjangoで構築されており、以下のアプリケーションが含まれます。

• 静的な内容を動的に出力するためのフラットページ（Django標準機能）
• del.icio.us、はてぶ、の特定ユーザのDjangoタグがついたブックマークを自動収集したアグリゲータ
• 特定のブログのDjangoタグがついたエントリを自動収集したアグリゲータ
• ニュースを配信するためのブログツール

海外での実績はあるものの比較的新しく、日本ではまとまった情報の無かったDjangoですが、Tips/ドキュメントの日本語訳/様々なリソースへのリンク/なによりも仲間が手に届く状況になったことで、より魅力的なフレームワークになったはずです。

今年の夏にはDjangoのバージョンが1.0になる予定です（現段階でも既にワシントンポスト等で使用されています）。

スーパーマリオのスーパープレイなんだけど、どうして後ろ向きにとんでんの？

おまけ。これもスーパーマリオか？

寝ろって？

Djangoに移行したこのブログですが、言及リンクのないトラックバックははじくという作りにしていました。
＃ちなみにこのDjangoのブログと/doc以下のドキュメント類の管理・表示に費やしたコードは、
＃モデルの記述を含め手抜きなので300行ちょい。用途がはまればDjangoは最強な気がする今日この頃

トラックバックの仕様を考えると（自動化は）かなり厳しいため、制限をはずしました。
トラックバックの送信では記事の一部しか送信されてこないため、記事の終わりに言及に関する記述等がある場合には受ける側は気づくことが出来ません。

方針はあくまで、トラックバックは対象の記事について言及あるいはネタ元としてより昇華させた場合にのみ受け付け、です。
記事を書く際に検索エンジンで関連する記事を探す人たちからのトラックバックは手動ではじきます。
ま、ここに広告トラックバックしても無駄ですが、一応宣言だけ（Alexaで10万位以内に入っているのはきっと何かの間違い）。

なかなか解放されなかったSubversionがいつのまにか全プロジェクトで使用可能になっていました。

実は、VPS7難民となってから公開する物については極力変わったアプリは使用しないようにしています（恐怖感有り）。
実際はDjangoやSubversionは使っていますので、公開用のSubversionやtracを自サイトに自前で用意しないという方針にしたいということです（日本のDjango何とかはブログとは別サーバを借りている）。
なので、sourceforge.netのsubversionは待ちに待ったサービスなのでした。

http://svn.sourceforge.net/viewcvs.cgi/workstyle-py/で現在のWorkStyle-Djangoのソースが参照できます。
一応MagicRemovalBranchの2509で動作するように修正済みですが、コードがとんでもないのでPythonWorkshop the Edge 2006が終わって余裕が出たら書き直そうと思います。きっと３分の１位のコード量になることでしょう。
Templateとか慣れてきたらDjangoの流儀に従うべきだと思い出したし。Djangoのテンプレートは素晴らしいよ！

そうそう、sourceforge.netのsubversionですが、使用開始は下記のようにする必要があります。

1. projectページでadminリンクをクリック
2. adminメニューが展開されるので、subversionメニューをクリック
3. subversionを有効にするチェックボックスにチェックを入れて、updateボタンをクリック（safariでは何故か失敗した）
4. で、migrationなりimportなりをすることになるのですが、この時点ではsubversionへの書き込み権限が誰にもありません。なので、Projectのユーザ管理でsubversionへの書き込み権限を与える必要があります（たぶんドキュメントに書いてない）。
5. 権限を与えたら、あとは好きにすればよいです（即座に反映されます）。
   

過去の記事を引っ張り出している人がいるので、まねをしてみようとしたんだけど、そもそもネット上に日記を書き出した時期にはもう戻れなかった（何年か前まではもう少しあったんだけど）。
今のドメインにしてからやろうとしてきたことがずっと同じだってのが哀しいかな。

ってか、2003/10に独自実装物でRSSを出してるって、結構偉くない？そうでもないか。。なぜかStrutsで実装してるしな。

今日まで出張中な訳ですが。。

データベースのビューはO/R Mapperで常に懸念事項としてあがってくる。
Djangoの場合もmodelの定義からデータベース構造ができあがる仕組みなので、ビューを使うのは一般的ではない。
ただ、実際はオブジェクトとして全部引っ張り出してから集計とかを行うのはばかげているので、ビューを扱って問題がないかを確認してみたというわけ。
実際に使っているのは、エントリのある月を一覧するところ（だってDjango本家のアーカイブはテンプレートに直に書いてあるんだもん。見間違え？）。
CREATE VIEW文は次のようにした。

create view djablog_archives as
 select
  yearmonth as id,
  yearmonth as yearmonth
 from (
   select 
    distinct(to_char(create_date, 'yyyymm')) as yearmonth
   from djablog_entry
   order by yearmonth desc
   ) archives
  order by id desc
; 

わざわざidという項目としても出力しているのは、Djangoがidを欲しがるだろうとの勝手な思いこみ。
みての通り、只単に年月をユニークに出しているだけ。
modelの方は、これまた汚いけど、こうなっている。

2006/03/17　追記
辞書を使えとの指摘。確かに！

class Archives(models.Model) :
    yearmonth = models.CharField(maxlength=6, blank=False)

    def get_path(self) :
        month = ''
        year = self.yearmonth[0:4]
        mm = self.yearmonth[4:6]
        print mm
        if mm == '01' :
            month = 'jan'
        elif mm == '02' :
            month = 'feb'
        elif mm == '03' :
            month = 'mar'
        elif mm == '04' :
            month = 'apr'
        elif mm == '05' :
            month = 'may'
        elif mm == '06' :
            month = 'jun'
        elif mm == '07' :
            month = 'jul'
        elif mm == '08' :
            month = 'aug'
        elif mm == '09' :
            month = 'sep'
        elif mm == '10' :
            month = 'oct'
        elif mm == '11' :
            month = 'nov'
        else :
            month = 'dec'
        return '/%s/%s/' % (year, month)

Archive表示が/yyyy/mon/を求めるので、変換している。
VIEWで出力する際にmonで出力でもいいんだけど、並べ替えが面倒なので、modelでmonに無理矢理変換しちゃった。
あとは、カスタムtagを作ってブログのベースで呼び出してぐるぐるすると、トップページとかに出ているArchivesができあがる。

まずはwwwからDjangoに移行しました。

本家Django-usersでも、Dreamhostでうまく動かないんだけど・・という叫びを発端に、Djangoを稼働させられるサーバ選びに一生懸命です。

ServInt

私はVPS7難民で、とりあえずservintに逃げ込んでいるのですが、月$49というのは今までVPS7を年$100で借り続けていた身としては（管理人さん、もうばらしてもいいでしょ？）つらすぎるのです。

Python-Hosting.com

で、日本のDjangoなんとかと、このブログの安息の地としてpython-hosting.comを選択しました。Django-usersにDjangoをサポートしたとの正式アナウンスがあったからです。個人ディレクトリにDjangoがインストールされるので勝手にバージョンをあげることが出来ました（branchを使っています）。名前の通りPythonに強いホスティングサービスなのでpythonもいっぱい入っています。
Djangoで作っているブログツールもある程度出来てきたので、二つめのドメインをDjangoに割り当てようとしました。あれ？あれ？virtualhostの設定が効かない・・・。trouble ticketを切ってみた所、「個人のapache2へリクエストがくる時点ではlocalhostで呼んでいるからX-Requestなんちゃらを使ってDjangoでディレクトリを振り分ければ出来るよ」と的確な回答。的確なんだけど・・・。LocationディレクティブでのDjango振り分けは可能なので、もう一個前にもうひとつDjangoをかませと。ロングランニングプロセスの利用可能メモリは30MBなのですよ。大丈夫そうな気もするけど、アプリもちょっと複雑化しちゃうしねぇ。

ちなみにPython-Hostingの仕組みはこうなっている：

1. 特定ドメインのリクエストをpython-hosting.comのapacheが受ける
2. ドメインからどのユーザのapacheに降ればいいかを判断して、localhostの特定ポートにフォワードする
3. ユーザのapacheはLocationディレクティブを使ってDjangoのアプリケーションを切り替える

mod_pythonを利用するDjangoやTurboGears（fcgi?）、cherryPyはロングランニングプロセスと呼ばれるサービスとなるので、月$15のplan2では１つ、月$25のplan3では2つの利用が可能。
ドメインを二つ、それぞれ別のDjangoアプリケーションで使用したい場合はplan3にしたほうが無難。
VPSで好き放題していたので、使えるapacheのモジュールが少なかったりしてちょっとげんなり。
PostgreSQLは8.02なのでオッケーでした(pycorgも1系でDjangoに最適）。

adiungo

で、世の中は29ユーロでdedicatedサーバを借りられる時代になっていることをDjango-usersのやりとりから発見。servintの$49より安いですわ。ただし、サイト的に英語が通じそうになかったのでそこは断念。

探す探すGoogleのスポンサー検索で探しました。

月$29でアメリカのdedicatedサーバを発見。悪くないんだけど、メモリが256MB。フィジカルメモリだから素敵ではあるんだけど、セットアップとか何かする度にお金がかかるみたい。

探す探す。
スイスのVPS（adiungo.com）が１サーバ50人プランで月$29。年払いにすれば月$20（二年は月$18）。

512MBのバーチャルメモリでバースト？が1GB。サーバ移民は１月分只になるらしいし、30日のマネーバックもあるから、試しに申し込み。Fedora Core2ってのが気になるけど、yumをさまよってみようと思う。
びっくりしたことにコントロールパネルが日本語だったよー。

迷走とりあえずまとめ

サービス	タイプ	管理	メモリ	月	年払い	備考
VPS7	VPS	UnManaged	?	$10	$100	残念ながらサービス停止
servint	VPS	Managed	256MB	$49	-	GoodPicさんも使っている
python-hosting	shared	Managed	30MB	$15	$150	PythonのOSSは無料でホスト
adiungo	VPS	Managed	512MB	$29	$240	スイスだけどサイトは英語

さてさて、hostingはどこに落ち着くものか。お金がかかるなぁ。

Django Gets Transactions(Push cx)

Djangoの最大の欠点だったトランザクションがsprintにて実装された模様です。

現時点ではブランチ(MagicRemoval)にたいしての実装ですが、３月中にはトランクとマージされる予定なのでリリース版に取り込まれるのも時間の問題でしょう。

ちょっと気になったのは、サンプルコードではビューファンクションに対してトランザクションを使用することを@デコレーティブで宣言しています。DjangoのO/R Mapperは単体で利用可能（シェルからもオッケー）なのですが。

まさに今、COREBlog2のエントリーを抜き出してDjangoで作成中の代替Blogツールにデータとしてぶち込む様なことをしている（そしてころころスキーマを変えている）ので、失敗したときにはロールバックをしたいところ。