<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
		xmlns:xhtml="http://www.w3.org/1999/xhtml"
>

<channel>
	<title>you know something? &#187; Django</title>
	<atom:link href="http://yamayo.to/wp/category/django/feed/" rel="self" type="application/rss+xml" />
	<link>http://yamayo.to/wp</link>
	<description>Use it for myself.</description>
	<lastBuildDate>Tue, 05 Oct 2010 20:36:33 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://yamayo.to/wp/category/django/feed/" />
		<item>
		<title>Is Rspec(or BDD) really the saviour?</title>
		<link>http://yamayo.to/wp/django/28/</link>
		<comments>http://yamayo.to/wp/django/28/#comments</comments>
		<pubDate>Mon, 19 Nov 2007 07:36:32 +0000</pubDate>
		<dc:creator>toomore_such</dc:creator>
				<category><![CDATA[Django]]></category>

		<guid isPermaLink="false">http://yamayo.textdriven.com/wp/?p=28</guid>
		<description><![CDATA[# -\*- mode: rst -\*- ある青年団体で開催されたマネージメントに関する講演で、こんな話を聞きました。 [ `コモディティ`_ で勝負する時の三要素 ] * 圧倒的に 価格競争力があること * 圧倒的に 利便性・柔軟性があること * 圧倒的に 安全・安心であること .. _`コモディティ`: http://d.hatena.ne.jp/keyword/%A5%B3%A5%E2%A5%C7%A5%A3%A5%C6%A5%A3 django やら何やら。 オープンソースコミュニティを彩る天才たちの成果物をありがたく使わせてもらう凡人の身としては、大変心に染みる話でした。 特に、三番目には本当に重要。なので、テストには特段重きを置いています。 それ故にかどうかは分かりませんが、顧客には成果物に満足していただいてはいるものの、最近は開発途中で大幅な仕様変更が発生することが多くて、自分的には理想に描くような三要素の結果が得られていないのが実情。 よく「アイジャルだからコードがモックアップになる」とか、「アイジャルだから修正が容易」とかいう話を聞きますでしょ? 私はあんなものマスコミの喧伝ないしは嘘っ八だと思っています。 やはり、コードを起こす前に打ち合わせをよくよく行なって、顧客の実情に適合した仕様に煮詰めることは大事だし、 開発段階もある程度に突入すると、修正が難しくなってくるのはどんな環境になってもそれほど変わらない、と思っています。 django で一番キツいのは、model の変更かな? rails を離れて早一年弱。migration だけはいまだに懐しかったりします(w さりとて、コンピュータ(死語?)に精通していない方が相手な訳ですから、漠然とした希望(or 状況把握)と実際のコードとのバランスを取るのは非常に難しい。 例えば、こんなケース。 打ち合わせの初期段階では予算が絡むので、決裁権の有るエラい方が相手。で、仕様(≒金額)がある程度煮詰まったら、テストリリースを持って現場へ移譲される。 しかし、移った方で「もうこんな古いやり方してないですよ」とか言われちゃうと、もう大変。「さぁて、どうすんだ」って感じ? ロボット三原則じゃないですが、上記三要素を自己適用して、「こうなったら何とかするっきゃない」というのは当然なんですが、 「自分的には理想に描くような結果が得られていない」と上述したのは、テストのために実コードを書いているのか、実コードのためにテストを書いているのか、ここからのフローが自分の中で明確に確立していなかったのが、一番の悩みだった訳です。 2ch風に「ちゃんと打ち合わせしろよ、ゴルァ！ボケがぁ！」と言われても仕方ありませんが、しかし、肝心の情報が途絶してしまっている状況の場合、要求を受けるだけの側としては、こういう例外が発生する確率をゼロにすることは不可能ですし、むしろ、こうした逆境にも「えいや！」ではなく、冷静に即応できる体制をホールドしておくことも大事、と私は思うんですね。というのは、やっぱり、せっかく製作する(した)システムな訳ですから、「便利だよ」と現場に使っていただくことが、私には何よりの報酬でもあるからです。 で、ここで、本題の Rspec(長い前振りだったなぁ…)。 このような状況を改善するための良い手法は無いものかと、以前から気になっていた Rspec をググってみると、こんなサイトを見つけました。 `Rubyist Magazine &#8211; スはスペックのス 【第 [...]]]></description>
		<wfw:commentRss>http://yamayo.to/wp/django/28/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://yamayo.to/wp/django/28/" />
	</item>
		<item>
		<title>a summary of Django&#8217;s security</title>
		<link>http://yamayo.to/wp/django/9/</link>
		<comments>http://yamayo.to/wp/django/9/#comments</comments>
		<pubDate>Thu, 10 May 2007 07:44:45 +0000</pubDate>
		<dc:creator>toomore_such</dc:creator>
				<category><![CDATA[Django]]></category>

		<guid isPermaLink="false">http://yamayo.textdriven.com/wp/?p=9</guid>
		<description><![CDATA[開発中は、お気楽なもので、 入出力をガンガン繰り返していましたが、 Rails で言うところの pruoduction 環境になって来ると、 そうもいきません。 なので、再度、確認の意味も含めて、 The Django Book を、よくよく読み返して、 ポイントを、ざっとまとめてみました。 SQL injection 普通に O/R mapper を使っている分には、 まったく問題は無いようですが、 特定のデータベースエンジン向けにチューンする場合には、 注意が必要なようです。 ただ、Database API reference にも、 By definition, these extra lookups may not be portable to different database engines (because you’re explicitly writing SQL code) and violate the DRY principle, so you should avoid them [...]]]></description>
		<wfw:commentRss>http://yamayo.to/wp/django/9/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://yamayo.to/wp/django/9/" />
	</item>
		<item>
		<title>about checking lists of TESTING RESPONSES.</title>
		<link>http://yamayo.to/wp/django/7/</link>
		<comments>http://yamayo.to/wp/django/7/#comments</comments>
		<pubDate>Wed, 09 May 2007 07:32:43 +0000</pubDate>
		<dc:creator>toomore_such</dc:creator>
				<category><![CDATA[Django]]></category>

		<guid isPermaLink="false">http://yamayo.textdriven.com/wp/?p=7</guid>
		<description><![CDATA[早速、備忘録として。 Test Client で気がついたこと。 get() や post() で TESTING RESPONSES を取得した後、 予想結果と実際の結果が、一致するかどうかを確認するよう、 あらかじめ unittest を書いておくことになりますが、 templates の構成によっては、 TESTING RESPONSES の context には気をつけた方が良い、 ということに、気がつきました。 私は、templates の構成を、 templates/base.html templates/app_name/page_00.html templates/app_name/page_01.html . . (以下、必要ページ数分続く) として、各 view の html は、 base.html の差分のみを記述するようにしています。 この場合、content は、 最終結果のみを返してくれるので、問題無いのですが、 context は、redirect だけではなく、 templates の使用回数分、リストに記録されています。 こちら( DjangoのViewをテストする &#124; スパムとか )では、 last_response = respon.context[len(respon.context) - [...]]]></description>
		<wfw:commentRss>http://yamayo.to/wp/django/7/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://yamayo.to/wp/django/7/" />
	</item>
		<item>
		<title>We must use a secure password.</title>
		<link>http://yamayo.to/wp/django/8/</link>
		<comments>http://yamayo.to/wp/django/8/#comments</comments>
		<pubDate>Wed, 09 May 2007 09:21:46 +0000</pubDate>
		<dc:creator>toomore_such</dc:creator>
				<category><![CDATA[Django]]></category>

		<guid isPermaLink="false">http://yamayo.textdriven.com/wp/?p=8</guid>
		<description><![CDATA[User の password について少々。 login() で何としても、認証が通過せず、 False ばかりが返ってくるので、困り切ってしまいました。 取りあえず、こんな感じで、 (self.user, self.user_created) = User.objects.get_or_create(username= 'ayu', defaults={'password': 'hogehoge'}) テストユーザを作ってみるのですが、何としてもダメ。 get() の呼び出し順か? とか、 @login_required な view しかダメなのかも、とか、 有らぬ方向に、どんどん進んで行ってしまいました。 最終的に、password は、sha に変換されていないとダメ、 ということに気がついたので、sha ライブラリで あらかじめ hexdigest を吐き出させておいて、こんな感じに、 (self.user, self.user_created) = User.objects.get_or_create(username= 'ayu', defaults= {'password': 'sha1$631a2$d2c019585aa2df606b8b52a14ca1d32832109d4c'}) 修正してみたところ、無事通過。 いやぁ。良かった、良かった。 と、ここで、 documentation の User authentication in Django を、ふと見ると、 User.set_password() が、あるじゃあ、ありませんか。 はぁ・・・ドキュメントには、ちゃんと目を通しましょうね。]]></description>
		<wfw:commentRss>http://yamayo.to/wp/django/8/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://yamayo.to/wp/django/8/" />
	</item>
	</channel>
</rss>

