LLRingのDjango製アプリ(フライング)
2006年08月28日(月) 01:20
LL Ringの「君ならどう書く」で作成したDjangoアプリケーションを暫定公開します。
LL Ringのサイト(かどうかはよくわかりませんが)で、正式に公開されることになると思いますので、あくまで暫定版ということでよろしくお願いいたします。
少し、というかたくさん補足説明をします(詳細はファイルの中のREADMEを必ず読んでください)。
LL Ringのサイト(かどうかはよくわかりませんが)で、正式に公開されることになると思いますので、あくまで暫定版ということでよろしくお願いいたします。
少し、というかたくさん補足説明をします(詳細はファイルの中のREADMEを必ず読んでください)。
以下長々と
- 作りの構成:見た目は管理画面風でしたが、データ登録に関する部分以外は管理画面の機能ではありません。
「今月の状況」「最近の状況」「明細」は管理画面のCSSを用いて、独自に作成したものです。 - 国際化:実はインチキ英語で国際化されています。ソースやテンプレートは殆どが英語で記述されています。
- 管理画面の「ドキュメント」というリンクから、ソースコードに記述してあるドキュメントが「テンプレートタグ」「テンプレートフィルタ」「モデル」「ビュー」というカテゴリに分かれて表示されます(インストールしてあるアプリケーションのもの全てが、アプリケーション単位に分割されて表示されます)。これは、コマンドをキックしたりすること無く、動的に生成・表示されるものです。
- タグ部分の実装は、Ivan SagalaevさんのTagアプリケーション v1.4を利用しています。タグの追加や「管理画面での」or検索は、独自コードはありません。
また、明細画面のタグ検索はand検索ができるようにしてあります。 - 「最近の状況」は、直近の3ヶ月を表示するようになっていますが、URLを手でいじくることによって、どんな期間でもグラフ・表ともに出力されるように作成してあります。
- 出費の管理画面では、既存の出費編集画面から一部の情報を変更して「新しく追加」という機能があります。頻繁に発生するものは日付だけかえればすみます。
- PyChartもRailsのGraphと似たような使い方だと思います(決して難しいものではない)。
ただ、折れ線グラフに微妙な罠があり、はまってしまいました。 - テンプレートが汚いのは、管理画面のCSS(XHTML)の構成を把握していなかったためです。本来は継承でブロックをうまく定義して、まとまりをわかりやすく、無駄を省いて記述が可能です。
- Djangoの動作環境についての質問で、意味不明な回答をしましたが、基本は「Apache+mod_python」「Apache+FastCGI」「lighttpd+FastCGI」が動作環境です。そうそう、Railsの開発サーバの5倍高速に起動する(マイ仕事マシン比)開発用サーバがついてます。詳しくは本家のWikiを参照してください。なんだかへんてこな環境もあります。
- 実はDjangoのInternalServerエラーページはすごいです(Debug時)
- プレゼン開始時に表示されていたデスクトップ画像は事件ではなく
恋故意です - Django勉強会、是非やりたいと思っています。マジでくる?
DjangoこそがPythonのWebフレームワークだ、とか
2006年08月19日(土) 13:51
RailsのStreamlinedアナウンスから面白いことに!
2006年08月18日(金) 22:57
誤読に対していただいたコメントや、喧嘩とかして欲しくないですけどね…(Usa*Usa日記)というエントリに、またまた勝手に調子づいてしまっていたことに気づきました。一部訂正等の修正を入れました。会社で同僚とわーきゃー言っている気分で書いてしまうことがよくあるので、気をつけないと。。。
Railsのblogに必見のエントリーが。
エントリー自体は、RailsのAjax ScaffoldをベースとしたDjangoのadminライクなStreamlinedに関するアナウンスなんだけど、コメントにDjangoのAdrianが登場し「失望した!単なるコードジェネレーションに失望した!」とのたまった。
すぐさまDHHによる反論(言い訳に聞こえなくもない(読み誤りの可能性が大いにあるので「言い訳」は削除))。DHHによれば、Scaffold自体も入門用として存在しているだけでなれてきたらスクラッチで書くべきものScaffoldはあくまで「足場」、StreamlinedについてもRailsのコアに取り入れるようなものではない、Djangoのadminのようにmodelにメタ情報を記述するのは気に入らないとのこと。
実は、streamlinedはコードジェネレーションだけではなく動的生成でも動作するらしい(本当のところどうなのかは知らない)。さらにさらに、auto_adminというRailsのDjango adminを作っている人がいたり(見た目は完全にDjango)、Railsで作っているサイトの管理画面にDjangoを使っている人がいたり(RailsのmodelをDjangoのmodelにする補助スクリプトあり)と、面白いことになっています。
RailsのAjax Scaffoldはなかなか見た目もよくて、関連も扱えるようになってきて、もう少しでadminになるんじゃないかと思っていた矢先の出来事でした。
海外のRails使っている人って、Djangoがいいっていう人がいっぱいいて、でもRailsに取り込もうとしていたりしてなんだか面白い(デザイナー達はDjangoへ逃げたりしてるようですが)。
(追記)実際のことを言えば、Djangoを使っている人たちもRSJが良いっていったり、Scaffoldが欲しいって言ったりしています。Scaffoldについては本家のwikiに利用可能なコードがあります。もちろんAdrianはコアに組み込もうとはしませんが。
そうそう、「RailsのコアチームはRailsがこうあるべきっている信念が感じられるけどDjangoには感じられない」っていうコメントにAdrianが切れてるのも面白いです。
私的には
世のAjax必須ムードにもめげず黒魔術を取り除くのに半年かけるのがDjango。
has_oneとbelongs_toを双方のmodelに定義しなければいけないDRYがRails。
って思っているんだけど、Django派だからかな。
ん?いや?、業務にRailsつっこもうとしてるんですからRailsラブですよ、もちろん。
複数スキーマ&ロジック満載データベースが含まれる業務系にRailsつっこんだチームなんてそうは無いに違いないぞ。
だれか、Railsの偉い人、Streamlinedの使い勝手とか具体的な動作とか、解説してくださーい。Rubyのコードは追いたくないもんで。。。catwalkと比べてどうなんだろう?
が、ここで大きな疑問が。
なんでDjangoを使わないの!?
本が無いから?
Python系の特徴ともいえる理路整然としたドキュメントがありますよっ(完全なる日本語訳もあるし)!
つーか、Pro Django 本出るし!
Railsのblogに必見のエントリーが。
エントリー自体は、RailsのAjax ScaffoldをベースとしたDjangoのadminライクなStreamlinedに関するアナウンスなんだけど、コメントにDjangoのAdrianが登場し「失望した!単なるコードジェネレーションに失望した!」とのたまった。
すぐさまDHHによる反論(
実は、streamlinedはコードジェネレーションだけではなく動的生成でも動作するらしい(本当のところどうなのかは知らない)。さらにさらに、auto_adminというRailsのDjango adminを作っている人がいたり(見た目は完全にDjango)、Railsで作っているサイトの管理画面にDjangoを使っている人がいたり(RailsのmodelをDjangoのmodelにする補助スクリプトあり)と、面白いことになっています。
RailsのAjax Scaffoldはなかなか見た目もよくて、関連も扱えるようになってきて、もう少しでadminになるんじゃないかと思っていた矢先の出来事でした。
海外のRails使っている人って、Djangoがいいっていう人がいっぱいいて、でもRailsに取り込もうとしていたりしてなんだか面白い(デザイナー達はDjangoへ逃げたりしてるようですが)。
(追記)実際のことを言えば、Djangoを使っている人たちもRSJが良いっていったり、Scaffoldが欲しいって言ったりしています。Scaffoldについては本家のwikiに利用可能なコードがあります。もちろんAdrianはコアに組み込もうとはしませんが。
そうそう、「RailsのコアチームはRailsがこうあるべきっている信念が感じられるけどDjangoには感じられない」っていうコメントにAdrianが切れてるのも面白いです。
私的には
世のAjax必須ムードにもめげず黒魔術を取り除くのに半年かけるのがDjango。
has_oneとbelongs_toを双方のmodelに定義しなければいけないDRYがRails。
って思っているんだけど、Django派だからかな。
ん?いや?、業務にRailsつっこもうとしてるんですからRailsラブですよ、もちろん。
複数スキーマ&ロジック満載データベースが含まれる業務系にRailsつっこんだチームなんてそうは無いに違いないぞ。
だれか、Railsの偉い人、Streamlinedの使い勝手とか具体的な動作とか、解説してくださーい。Rubyのコードは追いたくないもんで。。。catwalkと比べてどうなんだろう?
が、ここで大きな疑問が。
なんでDjangoを使わないの!?
本が無いから?
Python系の特徴ともいえる理路整然としたドキュメントがありますよっ(完全なる日本語訳もあるし)!
つーか、Pro Django 本出るし!
無理矢理Railsのajax_scaffold型にするとこうなる
2006年08月15日(火) 22:16
Ajaxじゃない版に引き続き、せっかくなのでAjax版も作ろうとしてみました。
結論から言うと、失敗しました。
いや、そりゃやろうと思えばできるわけですが、なんというか
気分転換に国際化を施しました。
gettextが無くて、英語のままになりました。。。
せっかくなのでOSから再インストールします。ので、バリデーションエラーがでると何も無かったかのように振る舞う状態でとりあえず「完」。正常系は動きます。もし動かしてみたいという奇特な人がいたら、settings.pyの下の方を修正して走らせてみてください(エラーハンドリングにチャレンジしてみても楽しいかも)。
結論から言うと、失敗しました。
いや、そりゃやろうと思えばできるわけですが、なんというか
バリデーションエラーをインターナルサーバエラー扱いにするのが嫌
なので。RailsのAjax ScaffoldでDjangoになじまなかったところ
- responseヘッダに対象のオブジェクトのIDを忍ばせるところ。
気持ちはわからんでも無いのですが、genericビューをラップしなければならなくて面倒でした。
ajax_address/address/views.pyのdetailとdeleteというファンクションが本来であればいらないファンクションです。
なので、本来ビュー(他で言うコントローラ)に書かなければいけないのはpurgeというデータを初期化する部分だけです。 - バリデーション等、RailsのManipulatorに引っかかったものをhttpのレスポンスコード500で返すところ。
普段の非Ajaxアプリで、バリデーションエラーはレスポンスコード200ですよね?私がおかしい?
Prototype.jsとかのエラーハンドラが、レスポンスコード500系を扱うからなんでしょうね。
innerHTMLに結果をそのまま書き込むタイプだと、このあたりはひじょうにつらい。
Djangoのgenericビューのリターンは既にテンプレートレンダリング済みなはずだから、ラップしてっていうのが簡単にできるのかを考えるのも嫌で挫折。
本当になえたところ
macbookを買ったので、試しにXCodeを入れずにDjango環境を作成しました。気分転換に国際化を施しました。
gettextが無くて、英語のままになりました。。。
せっかくなのでOSから再インストールします。ので、バリデーションエラーがでると何も無かったかのように振る舞う状態でとりあえず「完」。正常系は動きます。もし動かしてみたいという奇特な人がいたら、settings.pyの下の方を修正して走らせてみてください(エラーハンドリングにチャレンジしてみても楽しいかも)。
Django095イントロドラフト1
2006年08月12日(土) 23:33
さてさて、同僚にDjangoを教える必要があるので、ざっくりのざっくり。
Pythonをちょびっとと、Djangoをちょびっと。
Macbookを買ったら、OmniOutlinerがついていたので試しに使ってみたというのもある。
結局はOmniOutliner → HTML → PDFで出力した。
ReStructuredTextで表を作るのが大変じゃなければなぁ(結局表はまだ無いんだけど)。
PythonもDjangoも記述に誤りがあるかもしれない。あしからず。
#ファイルはトップページには出てきません、エントリ詳細に張り付いています。
Pythonをちょびっとと、Djangoをちょびっと。
Macbookを買ったら、OmniOutlinerがついていたので試しに使ってみたというのもある。
結局はOmniOutliner → HTML → PDFで出力した。
ReStructuredTextで表を作るのが大変じゃなければなぁ(結局表はまだ無いんだけど)。
PythonもDjangoも記述に誤りがあるかもしれない。あしからず。
#ファイルはトップページには出てきません、エントリ詳細に張り付いています。
Rails1.1.4が偉いことになっていたようなのを踏まえて、Djangoの場合
2006年08月11日(金) 20:39
セキュリティパッチをあてなさい、これは命令です!的な感じで、Railsの1.1.4についてRails界隈では大騒ぎになっていたようです(その1.1.5にも問題があったようで1.1.6がでています)。
RailsのセキュリティホールというかバグについてはRailsの人たちに任せて、Djangoにセキュリティホールが見つかった場合はどうすべきかについて。
Railsの騒ぎを受けて、Adrianがエントリを起こしています。
ドキュメントにあるように、security@djangoproject.comにメールにて通知してください。本当にコアなメンバにのみ通知されます。
コアなメンバは落ち着いてセキュリティホールを塞ぎ、アナウンスする方策やタイミングを検討し、適切に世の中に告知を行います。その際、セキュリティホールを通知した人にはおおよそのマイルストーンが通知されます。
http://groups.google.com/group/django-announce
RailsのセキュリティホールというかバグについてはRailsの人たちに任せて、Djangoにセキュリティホールが見つかった場合はどうすべきかについて。
Railsの騒ぎを受けて、Adrianがエントリを起こしています。
セキュリティホールを見つけたら
→ 絶対に公開しないでください。ドキュメントにあるように、security@djangoproject.comにメールにて通知してください。本当にコアなメンバにのみ通知されます。
コアなメンバは落ち着いてセキュリティホールを塞ぎ、アナウンスする方策やタイミングを検討し、適切に世の中に告知を行います。その際、セキュリティホールを通知した人にはおおよそのマイルストーンが通知されます。
Django-announceの開設
セキュリティ関連やリリースについてのアナウンスを流通させるためのメーリングリスト(リードオンリー)が開設されました。Djangoを使用している人は参加しましょう。http://groups.google.com/group/django-announce
Ajaxじゃないとすると、こうなる。
2006年08月11日(金) 15:36
Ajaxじゃないものでよいならば、Railsで作るAjax住所録とか、
「Railsで作るAjax住所録」をTurboGearsで作ってみたとかは、
次のようなmodels.pyを書けば完成する(見た目は、ここに出てくるような感じ)。慣れれば1分前後で完成。
1対1とか1対複数とか複数対複数とかも自動管理画面で扱えるよ。
追記、国際化用の _ をインポートするの忘れてた
さて、次はAjax版。
「Railsで作るAjax住所録」をTurboGearsで作ってみたとかは、
次のようなmodels.pyを書けば完成する(見た目は、ここに出てくるような感じ)。慣れれば1分前後で完成。
1対1とか1対複数とか複数対複数とかも自動管理画面で扱えるよ。
追記、国際化用の _ をインポートするの忘れてた
from django.db import models
from django.utils.translation import gettext_lazy as _
# Create your models here.
class Person(models.Model):
#入力がからだっったり、100文字以上だったりすると入力エラーメッセージが表示される
name = models.CharField(_('name'), blank=False, maxlength=100)
#入力があって形式がメールアドレスとして正しくないと入力エラーメッセージが表示される
email = models.EmailField(_('email'), blank=True)
#入力があって形式が電話番号として正しくないと入力エラーメッセージが表示される
tel = models.PhoneNumberField(_('Telephone'), blank=True)
#どんな入力でも良い
note = models.TextField(blank=True)
class Meta:
#デフォルトのソート順はnameフィールドで行う
ordering = ["name"]
#モデル自体の名前(単数形)
verbose_name = _('Person')
#モデル自体の名前(複数形)
verbose_name_plural = _('People')
class Admin :
#管理画面の一覧に表示されるフィールドとその順序の指定
list_display = ('name', 'email', 'tel', 'note')
#管理画面の検索で検索されるフィールドの指定
search_fields = ('name', 'email', 'tel', 'note')
#オブジェクトが管理画面で表示される際の表示
def __str__(self):
return self.name
さて、次はAjax版。
tabbloってやっぱおもろいな。
2006年08月09日(水) 02:16
tabblo
写真をはっつけてそれっぽいページを作るサービス(本来はそれを印刷することで成り立っているけど日本向けではないので協力できない)。Django製。Djangoで作れるのはCMSだけじゃないよ。
容量無制限で、iPhotoからアップできるからべんりー(ただし、今のところ転送速度が遅い)。
アップした写真がデフォルトで「仲間内に公開」なのがまたまたいいね。
日本語を通るように、要望を出そうか、しかしお金が渡らない日本からの利用で要望出すのもなんだな。
こんなんができる。
あぁ、そうそう。ちょっと前はやせてたんだよ(これは実際のサイズはプライベートにしてみた)。
写真をはっつけてそれっぽいページを作るサービス(本来はそれを印刷することで成り立っているけど日本向けではないので協力できない)。Django製。Djangoで作れるのはCMSだけじゃないよ。
容量無制限で、iPhotoからアップできるからべんりー(ただし、今のところ転送速度が遅い)。
アップした写真がデフォルトで「仲間内に公開」なのがまたまたいいね。
日本語を通るように、要望を出そうか、しかしお金が渡らない日本からの利用で要望出すのもなんだな。
こんなんができる。
McDonald's in front of Tokyu Hanzu. ... See my Tabblo>
あぁ、そうそう。ちょっと前はやせてたんだよ(これは実際のサイズはプライベートにしてみた)。
I was.... ... See my Tabblo>
Rails初心者の雑感
2006年08月02日(水) 01:32
ちょっと訳あってRuby on Railsを触っています。
RubyもRailsも非常なる初心者によるRails雑感です。いろいろといい手を知っている人は教えてください(あくまでレールに乗れない、RubyもRailsも初心者である、という条件を加味して読んでください)。
複数スキーマをレールに乗ったまま扱うのは非常に困難があるようです。
Railsのデータベース設定は、development/test/productionと3つのデータベースを設定できるようになっています。
rakeというJavaでいうant/Djangoでいうmanage.pyのようなコマンドを実行すると、引数無しの場合はAll Testが走ります。All Testが走る際に、rakeはdevelopment環境のスキーマをtest環境にコピーしようと試みます。これは、「開発環境のデータベースにはよけいなデータが含まれていて、テストがしにくい」という問題と「開発環境とテスト環境のデータベースを分けると、管理が大変」という二つの問題をクリアするための動作だと推測することができます。予期しないデータが含まれていると通らないテストというものに疑問がないことはありませんが。。
しかし、Rails本や世の中のRailsブログを見ても、「スキーマをコピーする」という行為が何を意味するのかが記述されていません。実際に何をしてくれるのか。何度かトライしてみたところ次の表のような感じでした(本当はもっときちんと検証したい。でもRadRailsでデバッガがキャッチされないエラーを吐くもんだから時間がない)。
たまに、存在するオブジェクト名ですというエラーをデータベースが返してくるので、既にテスト環境にコピー済みのオブジェクトをどこかで管理している可能性があります。また、fixtureというテストで利用するデータをテストで定義してある場合には、対象のテーブルのデータを全部削除します(条件無しのDELETE文)。
対象のテーブルデータを全部消してしまうので、スキーマ違いのテーブルをシノニムで対処してしまうとシノニムの参照先のデータが消されてしまいます。よって、テスト環境には手動でテーブルを作成、fixtureでデータを投入する必要があります。(開発環境のデータを使いたくてテスト環境を全部シノニムにしたら開発環境のデータが全部消されます。きっと)
ビューは更新が可能なものでなければ、シノニムをテスト環境で利用しても問題なさそうですが、テーブルのシノニムが利用できないので、やはり手動で開発環境と同期をとる必要があるでしょう。
スキーマが複数あり、かつ一部が既存のスキーマである場合は、Railsでレールに乗ることはできません。海外でも正規化された既存データベースとの相性の悪さは話題になっているようです。
規模が大きくなければなんとか対応が可能な範囲だと判断しましたが、テスト環境ではなく、開発環境でテストさせてくれてもいいんじゃないかとは思います。
確かにスクリーンキャストを見たりしても、そんな雰囲気があります。
しかし、実際はモデルごとにバリデータを定義します。せっかく変数を書かず空っぽなActiveRecordの継承クラスに、書いていない変数名を指定してバリデータを定義します。
必須バリデータと、最大長指定バリデータを一つのカラムに対して指定するがあるとすると、書いていない変数名を2行に書く必要があります。
結局書くのであれば、DjangoやTurboGearsのようにモデルに変数(カラム)の型を指定する方がスマートな気がしますが。本番環境のmigrate用の記述もDRYとしては?
ただし、表示されるメッセージが英語です。日本語化したいのですがデフォルトのメッセージのpoとmoがどこに含まれているのかがわかりません。どなたかご存知の方、教えてください。全部はじめからやるのはおかしいし。
探す必要もありませんでした、設定すれば自動的に日本語が表示されます。
RubyもRailsも非常なる初心者によるRails雑感です。いろいろといい手を知っている人は教えてください(あくまでレールに乗れない、RubyもRailsも初心者である、という条件を加味して読んでください)。
既存データベースとの連携
複数スキーマをレールに乗ったまま扱うのは非常に困難があるようです。
Railsのデータベース設定は、development/test/productionと3つのデータベースを設定できるようになっています。
rakeというJavaでいうant/Djangoでいうmanage.pyのようなコマンドを実行すると、引数無しの場合はAll Testが走ります。All Testが走る際に、rakeはdevelopment環境のスキーマをtest環境にコピーしようと試みます。これは、「開発環境のデータベースにはよけいなデータが含まれていて、テストがしにくい」という問題と「開発環境とテスト環境のデータベースを分けると、管理が大変」という二つの問題をクリアするための動作だと推測することができます。予期しないデータが含まれていると通らないテストというものに疑問がないことはありませんが。。
しかし、Rails本や世の中のRailsブログを見ても、「スキーマをコピーする」という行為が何を意味するのかが記述されていません。実際に何をしてくれるのか。何度かトライしてみたところ次の表のような感じでした(本当はもっときちんと検証したい。でもRadRailsでデバッガがキャッチされないエラーを吐くもんだから時間がない)。
| DBオブジェクト | テスト環境へのコピー |
|---|---|
| テーブル | ダンプして、Create? 文字セマンティクスをchar設定しているUTF8のOracleデータベースの場合、 きちんと開発環境のカラムサイズの4倍のサイズで非char設定してくれます。 ただし、4倍した際にvarchar2の最大値4000を超えるようなカラムが対象の場合は、 ひそかに4000に設定します(エラーとはなりません)。 |
| シーケンス | テーブル名から自動で作成(開発環境のものは無視) |
| シノニム | なにもしないけど、条件次第でデータを消す |
| ビュー | なにもしない |
たまに、存在するオブジェクト名ですというエラーをデータベースが返してくるので、既にテスト環境にコピー済みのオブジェクトをどこかで管理している可能性があります。また、fixtureというテストで利用するデータをテストで定義してある場合には、対象のテーブルのデータを全部削除します(条件無しのDELETE文)。
対象のテーブルデータを全部消してしまうので、スキーマ違いのテーブルをシノニムで対処してしまうとシノニムの参照先のデータが消されてしまいます。よって、テスト環境には手動でテーブルを作成、fixtureでデータを投入する必要があります。(開発環境のデータを使いたくてテスト環境を全部シノニムにしたら開発環境のデータが全部消されます。きっと)
ビューは更新が可能なものでなければ、シノニムをテスト環境で利用しても問題なさそうですが、テーブルのシノニムが利用できないので、やはり手動で開発環境と同期をとる必要があるでしょう。
スキーマが複数あり、かつ一部が既存のスキーマである場合は、Railsでレールに乗ることはできません。海外でも正規化された既存データベースとの相性の悪さは話題になっているようです。
規模が大きくなければなんとか対応が可能な範囲だと判断しましたが、テスト環境ではなく、開発環境でテストさせてくれてもいいんじゃないかとは思います。
DRYというかActiveRecordについて
Railsというと、ActiveRecordが有名で、プラスScaffoldで「データベースが変わっても全然問題ないよー。CRUD簡単だよー」というイメージがあります。確かにスクリーンキャストを見たりしても、そんな雰囲気があります。
しかし、実際はモデルごとにバリデータを定義します。せっかく変数を書かず空っぽなActiveRecordの継承クラスに、書いていない変数名を指定してバリデータを定義します。
必須バリデータと、最大長指定バリデータを一つのカラムに対して指定するがあるとすると、書いていない変数名を2行に書く必要があります。
結局書くのであれば、DjangoやTurboGearsのようにモデルに変数(カラム)の型を指定する方がスマートな気がしますが。本番環境のmigrate用の記述もDRYとしては?
i18nについて
Railsにはデフォルトのよく使うバリデータがついています。また、バリデータで検証エラーとなった場合には、Scaffold画面に自動でエラーメッセージが出ます。便利です。探す必要もありませんでした、設定すれば自動的に日本語が表示されます。
