【Python】Webフレームワーク Djangoスレ Part2
■ このスレッドは過去ログ倉庫に格納されています
LL言語「Python」で実装されたWebフレームワーク Django
Web開発する上で必要となる機能がそろっており、
管理サイト画面を自動作成できるなどの特色を持ちます。
前スレ
【Python】Webフレームワーク Djangoスレ Part1
http://kohada.2ch.net/test/read.cgi/php/1156612854/
本家サイト
http://www.djangoproject.com/
日本語ユーザ会「Djangoと日本の仲間たち」
http://www.djangoproject.jp/
日本語解説サイト
ttp://ymasuda.jp/python/django/index.html
解説本(英語) 「Pro Django:」2006年10月30日出版予定
ttp://www.amazon.co.jp/gp/product/1590597257/
あなたがDjangoを利用すべき10の理由(和訳)
ttp://www.everes.net/2006/jan/30/3042306a305fdjango3092522975283059304d10306e74067531/
IT Pro記事
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060410/234868/
IBM developerWork記事
ttp://www-06.ibm.com/jp/developerworks/linux/060802/j_l-django.shtml せやな。何も貢献してない人よりも
貢献しているってだけだな。 djangoは他の国のもあまり翻訳進んでなさそうだな manage.py runfcgi socket=hogehoge daemonize=falseでFastCGIを起動すると、kill -SIGTERMで死んでくれない。
defunctだからってことはないと思うけど、チュートリアルとか見ても殺すのにkill $(cat pidfile)だけなんだよなぁ。 自己解決。
実際はmethod=preforkとしてたんだけど、コレが良くなかったみたい。
Python3+Django1.8で動かしていて、runfcgiに必要なflupパッケージにflup6を使っていて、コイツがpreforkモード時の
シグナルの取り扱いにバグだかなんだか分からないがちゃんと拾ってくれなかったのが原因だった。
preforkにしたのは公式やWeb検索であったからで、とくにマルチプロセスにする意味もないのでmethod=threadedにしたら
問題なく動いた。
まぁ、どうせuwsgiとか使うのが常套なんだろうから大して役に立たないけど、情報展開。 無料でdjango動かせるところがいいんだけど
俺の知ってる限りだとdjangoのバージョンが古いんだよね
1.8が使える所があったらいいんだけど ロケールが日本の時のnaturaltimeで未来の分数に「今から1時間」みたいなの気持ち悪い
この訳を考えたやつ出てこいよｗｗｗ >>418
無理に翻訳しなくていいから
母国語で書いて！ まだ1.4がメンテナンスされていたのかよ
さっさと切ればいいのいのに Djangoについて勉強したいのですが、何かいい資料はないでしょうか?
英語の資料とか勉強過程で読んで来たのですが、なかなかしんどくて
できれば日本語の本があればいいのですが >>421
かってにマルチしないで･･･
>>422
やっぱ洋書が一番ですかね
プログラマーやってると英語できないって致命的だなぁと思います 特定のコンセプトなしに自由に利用することができるフリーな掲示板です。
自由なスレッドの作成、投稿にコメントの付与など３次元で楽しめます。
URLの投稿でのサイトの内容を画像でキャッシュします。
履歴も表示することができ、サイトの保存にも役立ちます。
また、RSS配信の記事を一覧で表示するニューススレッドを追加しました。
http://fluid.twolineprj.com/twoline/entry
（スマートフォンにも対応）
気軽に投稿してみてください。
また、新規サービスも続々追加予定。
こんな機能があったら・・などご意見も絶賛募集中！ 本を買わずとも、とりあえず思ったとおりに動かすようなのは日本語のページ見ながらでもできると思う。
ただ、なんというかべからず集というかベストプラクティスというかそういったものを体系的に学ぶとなると、書籍なのかな 洋書がいいよ。なんてったって要所を抑えているからね。ばいちゃ ★桐光学園中学校高校バスケットボール部 インターハイ出場
桐◎学◎中学校の試験中は、お父さんも気を使っていたみたいで、
試験が終り週末に私(しまんざき結子)が自宅アトラス調布の嶋ザキ家のキッチンで洗い物をしている時襲われ？ました。
＾＾急に後ろから抱きしめてきた。 「慎太郎お父さん！」 言ったけど、構わず私の、、耳を舐めてチンコが勃ってました。
兄は万引き東京電機大学中学校しまんざき亮すけ（介）しまんざき結子=もと稲城市立向陽台小学校評判 万引 とぐぐれば顔！） 転職時の注意事項。
下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される 742 デフォルトの名無しさん sage 2016/01/26(火) 11:04:43.37 e3nmXFm7
そうか、やっぱ遅いのか
pypy使えば少しは早くなるのかな？
PythonはTracで感じたけれど、スクリプトじゃなくアプリケーションレベルになると極めて遅い印象なんだよな
Tracだけかもしれないけれど
Dropboxは通信が関係してくるので遅さは仕方がないけれども
Djangoスレなんて専用のがあるんだな
そっちに行ってみよう データベースに性別で男か女かだけを0か1で入れたいんだけど、こういう場合でもPositiveSmallIntegerFieldがいいのかな？
かなり冗長な気もするけれど >>433
で、Fieldはどれがいいの？
SmallIntegerと、そのISOに反してMとFでやった場合のChar(max_length=1)ではどっちが小さく出来るのかなと フォームで生年月日を、と思うのですが何かいい方法はないでしょうか？
http://www.ahref.org/doc/hinagata/yyyymmdd.htmlのように、
year = forms.ChoiceField(
label=u'year',
choices=(
(1900, year = forms.ChoiceField(
label=u'year',
choices=( [_ for _ in range(1900:2017)] >>436
あぁ、そういう事出来たんですね
全く考えてもみませんでした（情けない）
ありがとうございました Djangoってなんでこんな分かりにくいんだろうか？
自分でPHPで作ったほうが遥かに楽で早く実装できると思う たしかに分かりにくいけど一度仕様を把握してしまえば大規模なの作る場合はDjangoのほうが向いてると思う
ぶっちゃけ個人でやるならphpのほうが楽だけどな ほかの軽量以外のフレームワークも全部分かりにくいとかぼやいてそうだなw 誰かDjango1.9を翻訳してくれ
1.4は古すぎて、仕様が違うところがチラホラ
で、エラーと戦うのが面倒くさい 英語わからんでも、ソース読んだらだいぶ分かるようになった。 今のDjangoはマニュアル読んでも分かるように、1.4とは結構文法が違ってきている
日本語に翻訳するべき時期には来ているとは思うね GZip middlewareなんかも、1.4のマニュアルにはセキュリティ問題のこと書かれてないもんな
SecurityMiddlewareもない
1.4のマニュアルはもはや役立たずだよ
つまり、英語が出来ないとDjangoは使ったらダメくらいになってるな Django1.9は1.4とは別物
マニュアル1.4によく載っていたmodel内の__unicode__すらもはや非推奨
日本語訳の1.4は今や無用の産物
むしろ混乱する
英語出来なければDjango1.9は使わず、マニュアルが日本語対応している1.4使うべき 古いドキュメントを検索から消し去る方法ないのかねぇ。
jQueryのあれも消えて欲しいんだが。 あの翻訳システムに登録して、おまえ等で少しずつ翻訳してくれよ… >>450
これ翻訳したあとの文章をどこに入力するの？ >>449
googleなら時期指定出来なかったっけ >>452
初心者に対して悪い影響を与えるから
ネット上から消えて欲しい 何にせよ、日本語の情報が少ないのと、古いがために日本では使いにくいと思われるだろうな
日本では断然PHPだろうし
PHPには勝てないよ
ちなみに面倒くさかったけれど、1.9の英語のマニュアル殆ど読んだ
1.4とは違う部分が多い 俺は1.8から始めたんだけど、それでも1.4のドキュメントは最初の最初は役に立ったよ。
後はひたすらググって作ってきた。
そのググった結果でやっぱり英語の1.9のドキュメントが結構ヒットするから、自然と読んでるようになったなぁ。
これを1から読んでたら多分挫折してた 俺が一週間ぐらいで私的に翻訳してた内容を何ヶ月もかかってリリースしてるダメな翻訳チーム
もういい加減こんなペースで活動してますアピールしてるのださいだけ チームってか今誰か翻訳してんの？
アピールってなんだ？
批判だけして貢献できない癖に俺有能アピールはダサいだけ() 翻訳してますアピールしてほとんど活動してないよりかはまし >>459
んなこたない
オレオレ翻訳アピールして全く活動してない奴よりは少なくともマシ こんなんで活動してますって言えるなら他のOSSのドキュメント翻訳チームだったら首だよ首 文句言うなら、誰か勝手に翻訳して公開したらいいんじゃないか？ 今月から触りだしてネットで人のソース見ながらAPIまでは作ったけど難しい 1.9はやらなくていいんじゃない？1.9から使えないものはログにでるし。
1.8がLTSだから1.8やるといい。そろそろ1.8がリリースされて1年だな。
あと2年のサポートだが、Django2系が出たらそっちがLTSになる。 自前のアプリで、管理サイトのlist_displayで表示項目と順序を制御するような事を実現したいのですが、参考になる情報源ないでしょうか。
ログインしたユーザーにより、あるモデルに対してユーザーAは項目1と項目2だけ、ユーザーBは項目2と項目5を表示するような事がしたいのです。
表示カラムモデルのようなものを作って、セッションからユーザーを特定し、対応する表示カラムモデルを取ってきて、それを元にコンテキストを生成すればなんとかなるかなと思ったり思わなかったり試行錯誤で悩んでいます。 ttp://qiita.com/44d/items/897e5bb20113315af006
恐らく似たような事例を見つけました。 >>466
ユーザが2人とかなら管理画面分ける方が楽かも。
正攻法ならModelAdmin.changelist_viewを継承していじったらいけない？ >>468
ありがとうございます。内容についていけてませんが、contrib/adminの中を漁ってみることにします。
自前アプリでやりたいだけなので、汎用的に作ってあるadmiサイトよりは簡単なのだろうと思いますが、そのadminサイトの中身なので難しいですね。。。 もう１ヶ月も投稿ないのか？
慣れたらDjangoが一番楽なような気がするのは俺だけか？
PHPのFWよりもいい気がするけれど
まぁガチガチなところがあるので、Ajaxとかの実装に少し悩んだりしたけれど
DB周りのフィールド名とかもハマった 最初の設計が悪かったせいなんだけど、途中でapplicationの名前を変えると
テーブル名変えたり色々とめんどくさいね。 ナビゲーションメニューのような共用のテンプレートを作って他のテンプレートに埋め込めますか? >>474
共通のものを含むベースのテンプレートを作ってそれを継承するのがマニュアル的なやり方じゃないかな？ >>475
調べてやってみます
ありがとうございます マ イ ン ド コ ン ト ロ ー ル の手法
・沢山の人が、偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い
靖 国 参 拝、皇 族、国 旗 国 歌、神 社 神 道を嫌う カ ル ト
10人に一人は カ ル ト か 外 国 人
「ガ ス ラ イ テ ィ ン グ」 で 検 索 を ！ WSGI周りの理解がダメなのか、調べたとおりやってもデプロイできないorz
実行者がapacheになるとパスが変わったりするのだろうか。 漏れはあきらめてapache用のdjango-cgi.pyを使ってる 上手く行ったと思ったら数時間でアクセスできなくなって再格闘中。
トータルで７日くらいやってるが諦めて他の方法にしたほうが良さそう。。。 諦めきれず再格闘。macだからなのか、apacheが使ってるhttpdがapple製のdeamon？なのが原因なのか、多分wsgiにsetuidで権限を付与する所で失敗してバグってる模様。Linuxだったらもう少し楽に設置できてたのかなぁ。 >484
まずはVirtualBOXとvagrantを入れてみよう。 申し訳ないんですがやっぱりWebアプリをdjangoで作るのはやめるべきだという結論に達しました。
Rubyは嫌いだけどやるならrailsのほうがいいです。
djangoが動かせるフリーのクラウドサーバも極少ないですし、あったとしてもバージョンが古いんですね。
django 1.9に対応したサーバなんてないんですよ。 >>485
堪忍してherokuにインストールしました。。。 ruby上で動くpythonがあれば解決する気がする たしかにDjangoは環境構築とメンテで時間取られる。
自分のサービスならまだしも、人のサービスを開発するとなると、
サーバー選択の時点でDjangoは除外せざる得ない。 Python3でwebsocketを使えるDjangoのフレームワークってありますか? 日経とかGunosyとかDjango本出してくれたまへよ 相変わらず投稿ナッシング！
Python使いにはDjango扱いやすいと思うんだけどなあ
少しお金かかるけどGAE/FEにものせられるよ？ 初心者(web経験なし)
一通り、チュートリアルに目を通しましたが、
殆ど解りませんでした
サンプルプロジェクト一式を配布しているサイトなどは無いでしょうか？ 世の中 single page application にいってるからな python使いたかったけど初心者だから情報の少ないDjangoよりrailsの方が勉強しやすいと思ってrailsに乗り換えた それでいいんじゃね？
pythonはドキュメント充実してるけど
djangoのチュートリアル読んで理解できないレベルなら
勉強しようとしても無駄
自分の理解出来そうなとこから始めるのはいいと思うよ
今後はrails頑張ってね 20年くらいメンテ続けてくれるやつを選べ
10年じゃだめだ 機械学習の盛り上がりで
pythonは日本でも一気にメジャー言語になったのに
いまだにdjangoは盛り上がらないね
何故なんだろか
みんなflask使ってんの？ 学習コストの問題じゃないか
色々できるからそのぶん色々勉強する必要がある 瑕疵担保責任（かしたんぽせきにん）
納品されたシステム、プログラムに不具合があった場合、10年後でも無償で修理してもらうことが可能になった。
民法改正で事実上期限が「無制限」になった
不具合を指摘されたらすぐに行動をとるべし 納品物に不具合があれば損害賠償を請求される可能性もある
http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt
改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求められるとしている
全ベンダーが泣いた民法改正案を解説しよう その1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html
ポイント1：修補や損害賠償、契約解除の期限がなくなる
従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、11年後まで請求可能なのだ。
もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
重大な脆弱性が現バージョンから発見されました。こちらでアップデートしたところ、起動ができなくなりました。
至急弊社に来て修正作業をお願いします。なおお金は払わない。また営業に損失が出たので損害請求もする。 ■ このスレッドは過去ログ倉庫に格納されています
