You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Django は開発者がアプリケーションをすばやく構築できるようにすることを主な目的としています。 このフレームワークを習得すると、概念を本番運用が可能なウェブアプリケーションに変えるまでの行程が短縮されます。 ただし、その行程をさらに短縮したい場合は PyCharm での Django アプリの作成方法を学習することをお勧めします。 このチュートリアルでは、現在地の現在の気温を表示する簡単な Django アプリケーションを作成する手順をすべて説明します。 また、他のランダムな場所の天候を参照できるようにすることで、アプリに対話性を導入したいと思います。 このチュートリアルでは、以下について学習します。 PyCharm で Django プロジェクトを作成する。 モデル、ビュー、およびテンプレートを記述する。 API を呼び出して応答を処理する。 データベースに接続してデータを挿入する。
本記事は、boto3を利用して行っている。 準備と前項については以下記事を参照。 https://tech.tokiraku.com/archives/154 https://tech.tokiraku.com/archives/161 確認コードの再発行 登録が完了する前に確認コードを忘れてしまった場合の再発行。 cognito.forgot_password( ClientId=settings.APP_CLIENT_ID, SecretHash=secletHash, Username=userName ); パスワード変更 変更前のパスワードを利用して、パスワードの変更をおこなう。 認証がされていないとできない。 cognito.change_password( PreviousPassword=[古いパスワード], ProposedPassword=[新しいパスワード], Acc
この投稿は 「Django Advent Calendar 2020 - Qiita」 8日目の記事です。 akiyoko です。 この記事では、Django REST Framework(通称「DRF」)で API スキーマを自動生成する「API ドキュメンテーション」機能を簡単に利用する方法について説明します。 目次 はじめに DRF 3.12 の状況 【方法1】DRF 標準の generateschema コマンドを使ってスキーマファイルを出力する 【方法2】drf-spectacular を利用する 導入方法 Swagger UI 形式の APIドキュメント画面 ReDoc 形式の APIドキュメント画面 カスタマイズ まとめ 宣伝 検証環境 Windows 10 Home Django 3.1 Django REST Framework 3.12 はじめに Django REST
Djangoは管理者ページが強力なのが良い所だが、適当に使ってるとORMが雑なSQLを発行してしまうのでケアする。 まだ使い初めたばかりなので、適宜追加していく。 querysetを上書きして一覧ページのSQLを最適化する list_displayにForeignKeyのフィールドを含んでいる場合 select_related が有効になる。が select_related は null=True なFKフィールドのリレーションを辿らないため、レコードの数だけ個別のSQLで対象を取得してしまう。よって一覧ページを開いた時にSELECT文が400回ぐらい発行されたりする。 また、 select_related は null=False なFKフィールドをどこまでも辿るため、10個や20個のテーブルとJOINするSQLになる事がある。 うまい具合にやるには queryset を自分で定義する。
Djangoでアプリケーションを作っているとアクセス制御をしたくなることがあります。たとえば、会員サイトではプレミアムユーザと一般ユーザによってアクセスできる情報に差を付けたいことがあるでしょう。こういった機能は、少し規模の大きなサイトではよく見かけます。 Djangoでアクセス制御をする方法はいくつもあります。その中にはDjango組み込みの方法やアプリケーションとして提供されている方法もあります。本記事ではそれらを比較してどのように使えるのか、どういった場面に向いてそうなのかといったことを確認します。 本記事の構成は以下の通りです。 Django組み込みのパーミッション django-guardian django-role-permissions django-rules Django組み込みのパーミッション Django組み込みのパーミッションは、ユーザかグループに適用できるモデル
バックエンドを開発していると、秘密にしたい値がどうしてもでてきますよね。 AWSのシークレットキー・APIキー・DBの接続情報等… ただ、それをsettings.pyでハードコードしてGitで管理というのは楽ですが正直セキュリティ的によろしくありません。 となると、「環境変数で管理しよう」となってくる事が多いと思いますが、 単純に環境変数にすると開発環境での管理が面倒になる場合もあります。 とりあえず環境変数にした場合の罠 開発環境はMac。 IDEはPythonista御用達のPyCharmを使います。 環境変数設定ファイルを作成 # MySQL DB_NAME=db_name DB_PASSWORD=hogepass DB_USER=hogehoge DB_HOST=127.0.0.1 DB_PORT=3306 DB_ENGINE=django.db.backends.mysql #
今回の内容 前回はDjangoの実践的なテストの書き方と、CircleCIを使った継続的インテグレーションについて解説しました。前回までのコードは以下から取得できます。 massa142/modern-django at volume3 第4回となる今回は、まず環境変数について取り上げます。環境変数を用いたsettingsファイルの書き方を紹介した後は、Angularを使ってカンバンボードのUIを実装していきます。 環境変数 環境毎に異なる値としては、データベースの接続に必要な情報やTwitterなど外部サービスの認証情報等が思い浮かぶと思います。これらの設定を定数としてコード上で管理することはもちろん可能ですが、セキュリティと保守性の観点から推奨されません。「The Twelve-Factor App」の教えにのっとり、設定は環境変数から渡すようにしましょう。 「The Twelve-F
Welcome to Djangosnippets.org, a site for users of the Django web framework to come together and share useful "snippets" of reusable code. If you're just here to browse, you can look through snippets organized by author, by language or by tag. You can also have a look at the top-rated snippets and the most-bookmarked snippets. If you'd like to contribute, sign up for a free account and you'll be a
Simple Way with Django + SQLAlchemy AT PyCon JP 2020 https://pycon.jp/2020/timetable/?id=203756 質疑応答 > Ryuji Tsutsui から全員に: 02:58 PM > INNNER JOIN > Nが1個多い? ほんとだ。slideshareにあげた資料、直せません! > Taku Shimizu から全員に: 03:00 PM > 「ドキュメントに記載されていない」なかなかのパワーフレーズですね でしょー > uranusjr から全員に: 03:04 PM > g2の別名はT3になるのはなぜですか? Djangoが自動的にテーブルを2回JOINすることもあって、そういう場合自動的にテーブル名の別名が付けられます。T2,T3,T4と連番で増えていきます。 たぶん、登場する3つ目のテーブル
Djangoはデータベースマイグレーションの機能を持っています。 ですが、 実際、Djangoマイグレーションってどう使うの? という疑問が多いかと思います。 docs.djangoproject.com この記事では、 マイグレーションを稼働中のアプリケーションに、無停止でどう反映すれば良いのか を説明します。 前提としてWebアプリ、データベースは本番環境に1系統づつあるとします。 基本的に無停止でマイグレーションを実行するのは 絶対に安全という方法ではないので、動作確認などをして慎重に反映する必要があります 。 無停止でマイグレーションを反映する基本 マイグレーションを 無停止で行う場合、「マイグレーションとアプリのリリースはどちらを先にすべきか」 という話になります (マイグレーションをするということは、アプリケーションの変更も必要になります)。 マイグレーションを先に実行して、ア
I wrote this post in 2010, more than 14 years ago. It may be very out of date, partially or totally incorrect. I may even no longer agree with this, or might approach things differently if I wrote this post today. I rarely edit posts after writing them, but if I have there'll be a note at the bottom about what I changed and why. If something in this post is actively harmful or dangerous please get
NHK.一応フラグ回収しときますねw*1 Django Advent Calendar 2018、14日目の記事です. Python(と他の色々なモノ)を駆使して野球をしています、 @shinyorkeと申します. PyLadies Tokyo - 4周年記念パーティのLTで、Djangoのアプリを披露したのですが、 そのときに触れることができなかったDjango REST Framework(DRF)のキャッシュ機構と、どういう考えで設計・実装したか?をメモ的に残したいと思っています. Djangoアプリのパフォーマンスや負荷対策をしたい方の参考になれば幸いです. TL;DR Django REST Framework(DRF)のキャッシュ実装はDjangoのキャッシュ実装そのまま データの賞味期限および、目的(LTのちょっとしたスパイス)に合わせていい感じにキャッシュを使おう*2 AP
これは Django Advent Calendar 2018 の 12/20 の記事です。 今回はこれまで Django アプリケーションをプロダクションで運用する際にやっておいてよかったこと、もしくはやっていなかったために苦労したことを覚書としてご紹介したいと思います。 The Twelve Factor アプリケーションへの準拠 ウォームアップ の2点です。 The Twelve Factor アプリケーションへの準拠 The Twelve Factor アプリケーションは Heroku の中の人が提唱したアプリケーションの構築方法です。 ひとことでまとめると 実行環境を問わないポータブルなアプリケーション にしましょうというものです。 例えば Django は開発サーバーがインクルードされていますが、プロダクションと同じ環境がローカルでも簡単に (manage.py runserv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く