CakePHPでステータスコード204がOK扱いにならなかった話

今年のQiita Advent Calendarに投稿予定です(CakePHPとDjango)。
いずれも12/20ですので、興味があればご覧ください。

CakePHP
Django

さて、今回はCakePHPに関する記事です。
結論から言うと、PRがマージされましたというお話です。

背景

私は自作アプリのログイン・ログアウトにGoの外部API(これも自作したやつです)を使っており、
それぞれ以下のように処理しています。

ログイン

  1. アプリ:ユーザ・パスワードで認証APIをコール(POSTメソッド)
  2. API:処理成功時、ステータスコード200とアクセストークン返却
  3. アプリ:アクセストークンを利用してユーザ取得APIをコール(GETメソッド)
  4. API:処理成功時、ステータスコード200とユーザ情報を返却
  5. アプリ:取得したユーザ情報をセッションに格納してログイン成功

ログアウト

  1. アプリ:アクセストークンを利用して認証解除APIをコール(DELETEメソッド)
  2. API:処理成功時、ステータスコード204を返却

ある時、CakePHP3を使ったアプリで、正常にログアウトした場合でもエラーログが出ていることに気づきました。

「エラーのくせに詳細が何も出力されないだと…」

という衝撃を隠しきれませんでしたが(笑)、一旦落ち着いて発生箇所を調査することに。

原因

コメントに書いた通りなのですが、上記コードをもとに説明します。

  • ログアウト時の処理2でステータスコード204が返ってくる(5行目)
  • isOk()の対象でないためif文に入らない(12行目)
  • レスポンスボディもないため、CakePHP側16行目Log::error()で出力する$bodyも空(17行目)

という流れで、何も情報が無いエラーログが出力されてしまっていたということです。
これだけなら「あえて204をOKしてないのかな」とも思えたのですが。

CakePHP3側の基底テストケースではまさかのOK対象内。

修正~PR

CakePHP側のコード修正・テストコードの修正および実施を行い、
それらのPRを出したところ、5時間ほどで無事マージされました。

ドキュメントは以前PRがマージされたのですが、コード側は初めてです。
「PRは内容に問題なければサクッとマージしてもらえるんだな」ということがわかりました。

とはいえ、IssueやPR作成時の説明にもあるように、注意する点もいくつかありますので、詳細は以下をご覧ください。
CakePHP コミュニティセンター

それでは、良いCakePHPライフを。

Gitでよく使うコマンドをメモしておく

バージョン管理システムであるGit。
便利なGUIツールはたくさんありますが、私はもっぱらコマンド派です。

今回はそんなGitで私がよく使うコマンドについて、備忘のために書いておきます。

リモート追加

ブランチをチェックアウト

リモートからブランチを取得

ブランチをマージ

git pullでfetch~mergeまでやってくれますが、私は上記をそれぞれ使っています。

変更をインデックスする

変更をなかったことにする

コミットする

コミットを取り消す

HEAD^は必要に応じて変更します(3つ前ならHEAD^^^など)。
この場合、push済みの場合は履歴を書き換えているので-fオプションが必要ですが、他の人に影響が出るので共用ブランチではやらないほうが良いです。

1つ前のコミットメッセージ変更

ブランチへpush

はオプションです。
-uオプションを付与することでデフォルトを設定できますが、実際はブランチをSwitchしながら色々やることが多いので、私は必ずどちらも打つようにしています。

ローカルの変更を一時退避

スタックになっているので、stashした数だけpopできます。

ちなみに、rebaserevertはあまり使いません。
ざっくり言うと、rebaseは指定のコミットまで戻って履歴操作(複数のコミットをまとめるとかコメント修正もこれで出来ます)、revertはコミットを打ち消すコミットです。

私は特によく使うコマンドをまとめたものを以下のようにエイリアスにしています。

このコマンドでは以下を実施しています。

  1. ローカルの変更を退避
  2. リモートにあるブランチと同名のブランチをローカルに新規作成
  3. リモートの変更をfetchして新規作成したブランチにマージ
  4. 退避していた変更を戻す

実際の作業時には、ローカルのブランチを別名にしたいとか、一気にやるとmergeのタイミングでconflictが起きた場合にpopを忘れそうといったケースが起こると思います。
上記はあくまでも参考ということで。

AWSで心がぴょんぴょんするんじゃぁ^~

皆さん、パブリッククラウド使ってますか。
無料利用枠があるサービスもあるので、個人で使っているという方も多いのではないでしょうか。

かくいう私もその1人です。
今回はその中から、Amazon Web Services(AWS)を利用したサーバーレスアプリケーションの作成について紹介します。

今回利用したサービス

  • API Gateway
  • Lambda
  • DynamoDB

作成したもの

処理の流れ

  1. API Gatewayで作成したエンドポイントをクライアントがコール
  2. API GatewayがLamdba関数を実行
  3. Lamdba関数内でDynamoDBのデータを取得し、呼び出し元(API Gateway)へ返却
  4. API Gatewayがクライアントへデータを返却

手順

アカウント登録

何をするにもアカウント登録しなければ始まりません。
手順はこちらをご覧ください。

登録後12ヶ月の無料利用枠があり、この間はほとんどのサービスが無料で利用できます。
にもかかわらずクレジットカードを登録するというのはやっぱり気になるところではありますが、
従量課金という仕組み上(12ヶ月中であっても有料サービスを使えば課金が発生するため)やむを得ないのでしょうね。

なお、今回利用するリージョンはいずれも「ap-northeast-1」です。

IAM(Identity and Access Management)ユーザ登録

IAMは、ユーザに適切な権限を割り振って管理するための仕組みです。
今回は必須ではありませんが、登録時のルートアカウントを使い続けるのはセキュリティ的にお勧めされていないので、AWSを利用するなら作成しておいたほうが良いです(IAM自体は12ヶ月の無料利用枠後も無料で利用できます)。
「サービス」→「IAM」→「ユーザー」→「ユーザーの追加」で作成できます。
※ユーザーの作成およびポリシーの設定については本筋ではないので省略します。

テーブル作成(DynamoDB)

DynamoDBは、最近何かと話題のNoSQLデータベースです。
管理コンソールより「DynamoDB」→「テーブルの作成」でテーブルを作成します。
今回は以下のように定義しました。

  • テーブル名:categories
  • プライマリパーティションキー:category(文字列)
  • プライマリソートキー:sortOrder(数値)

NoSQLデータベースなのでキー以外は自由に設定できますが、今回はとりあえず「message(文字列)」というフィールドに表示したいメッセージを格納します。

関数作成(Lambda)

Lambdaは、指定したイベントが発生したときのみ動作する(=常時稼働しない)サービスです。
管理コンソールより「Lambda」→「関数の作成」→「一から作成」で作成します。
「カスタムロールの作成」を選択し、Lambda実行用のIAMロールを作成します。

なお、今回はこのIAMロールに「AmazonDynamoDBReadOnlyAccess」ポリシーを付与する必要があります。
管理コンソールより「IAM」→「ロール」→「上記で生成したロール名」を選択→「ポリシーのアタッチ」で上記をアタッチしてください。

言語は色々使えるのですが、今回はPython3.6を使いました。
以下のコードを入力し「保存してテスト」で関数をテストします。

Lambda関数が呼び出された際、まずlambda_handlerが実行されます。
引数eventにパラメータが格納されるので、それを利用してDynamoDBから値を取得します。

エンドポイント作成(API Gateway)

API Gatewayは、APIのエンドポイントを作成できるサービスです。
実際の処理は今回のようにLamdbaでも良いですし、他のAWSサービスでも良いです(もちろん、HTTPサービスもコールできます)。
管理コンソールより「Amazon API Gateway」→「APIの作成」を選択し、APIを作成します。
その後、実行するメソッドを追加します。

今回はデータを返却するだけなので「GET」のみ作成しました。
セットアップでは「統合タイプ」に「Lambda関数」を選択し、先ほど作成した関数のリージョンと名前を選択します。
なお、Lambdaにパラメータを渡すためには、統合リクエストを編集する必要があります。

「統合リクエスト」を選択し、「本文マッピングテンプレート」→「マッピングテンプレートの追加」で以下を入力して保存します。

最後に「アクション」から「APIのデプロイ」を選択し、ステージを決定のうえデプロイ完了です。
ステージエディターの「URLの呼び出し」横にあるURLが今回利用するエンドポイントです。

呼び出しは以下のようになります。

https://(エンドポイントURL)/(ステージ名)?category=(テーブルのcategory)&order=(テーブルのsortOrder)

できあがったもの

かなり駆け足、かつ途中端折っている部分もありますが、いかがでしたでしょうか。

所感

正直「こんなに簡単に実装できるのか」と衝撃でした。
IAMやLambda関数を利用したAPI認証も可能なので、モバイルサービスやSPAと連携したAPIも低コストで構築できるのではないでしょうか。
Lamdbaは常時稼働でない分、初回起動時の速度をいかに担保するかが重要に感じました。
今回の件と直接は関係ありませんが、IAMユーザはポリシー割り当てで結構ハマったので、そのあたりは次回以降に書きたいと思います。

ちなみに、これらの機能を使った別のアプリケーションをこちらに公開していますので、興味のある方はご覧ください。

Laravelでカスタムコレクションクラスを利用する

今回はLaravelのお話です。
先日5.5(LTS)がリリースされるなど最近何かと話題のLaravelですが、今回はそんな新しい機能の話ではありません。

Laravel5.xやCakePHP3.xでは、PHPの残念な配列(連想配列含む)を良い感じに扱えるCollectionというクラスが存在します。
上記2フレームワークでは、ORMを使ってDBへ問い合わせた結果がCollection型で返ってくるケースが多いこともあって、new Collection()するよりはそのインスタンスを使うケースのほうが多いように感じます。

通常のforforeachでループできることはもちろん、map()filter()といったデータの整形や絞り込みをメソッドチェーンで行えるので、直感的にコードを書くことができます。
そこで、「拡張コレクションを作って特定モデルの結果はそいつを使おうぜ」というのが今回のテーマです。

注意しないといけないのは、map()メソッドのように内部でコレクションを生成する関数を呼び出した場合です。
map()関数は、内部で保持しているインスタンスがModelでなかった場合、Collectionクラスを返します。
上記evenPosts()の例だと、メソッドが最終的に返却するArticleCollectionクラスが内包しているのは配列なので、この戻り値からさらにmap()すると戻り値はCollection型になってしまいます。
つまり、evenPosts()map()evenPosts()といった呼び出し方をするとエラーになります。

その場合は上記コードにあるように、継承元であるIlluminate\Support\CollectiontoBase()メソッドをオーバーライドすれば良いです。

同様のことがCakePHP3でもできるんじゃないかと思っているんですが、こちらは今のところIteratorクラスを使うことになりそうです。

Laravelはドキュメントも充実しているので、大体はそこから情報を得られます。
以下に私が利用しているサイトのリンクを掲載しておきます。

Javaで並行処理を書く

最近はPHPやGo、JavaScriptばっかりやっていて、ほとんどJavaを触らなくなっていました。
Java9もリリースされたことですし、ここらで少し触っておこうと思います。

今回やってみるのは並行処理です。
以前、仕事で「Javaでバッチ処理」を実装した際、「メインスレッドと別スレッドでバッチを実行させる」という対応をしました。
いわゆる並行処理です。

並行処理とは

1つのCPU上で複数の処理を行うこと(この場合、実行順は保証されない)

並列処理とは

複数のCPUで1つの処理を行うこと(時間のかかる処理を分散させる)

ちなみに、JavaScriptでPromiseやコールバックを使って処理するケースは前者です。
並列処理は計算・演算面で使われるケースが多い印象です。
今回Javaで実装したのは並行処理です。
ExecutorServiceFutureを使います。

  • コード

  • 結果

一番処理に時間がかかっているタスク(8件目)とほぼ同じ時間でメイン処理が終了したことがわかります。
また、出力内容からスレッドが使いまわされていることもわかります。

いかがでしたでしょうか。
意外と簡単に実装できたことと、このjava.util.concurrentパッケージはJavaSE6からあったことが衝撃でした。
ちなみに、GoならGoroutineという機能があるので、もっと簡単に実装できます。
※ただし、プロセスやスレッドとは厳密には異なるため、アプローチや考え方が少し変わります。

余談として、内容的に大したプログラムではありませんが、メソッド宣言でfunctionと書きそうになったり、変数宣言でvalとか書いてしまい、コンパイラに怒られっぱなしでした。

今日からあなたもCakePHPer

昔の記事を読んでいると、「いろんな意味で若いな」と思いますね。
そんな自分もアラサーです。
イメージしていた姿とは大きく違っていますが、まあ色々経験した結果かなとプラスに考えておきます。

さて、今回は、先日3.5がリリースされたCakePHPについて書きます。
私がPHPを学習する際、初めて触れたフレームワークがCakePHP2.xでした。
2.xの配列地獄をご存知の方は、3.xになった際のORMの変更に少なからず戸惑ったのではないかと思います(もちろん良い意味です)。
マイナーバージョンで大きい変更があることも少なくありませんが、ある程度の後方互換が維持されているのはありがたいですね。

最近はLaravelに人気を持っていかれている感はありますが、個人的にはCakePHP3が一番好きなフレームワークなので、いくつかおすすめポイントを書こうと思います。
PHPをある程度使っている方はもちろん、以前の私のように、

  • PHPフレームワーク使いたいけど何が良いのか
  • そもそもPHPの基礎がそこまで固まっていない

といった方も対象です。

「設定より規約(CoC)」という安全性

これが一番大きいと思います。
ファイル名・クラス名・ディレクトリ構成などの「決まり」に則って開発するということは、個人的にはプラスだと思っています。
ある程度の経験があるとこのあたりはどちらでも問題ないのかもしれません。
ただ、PHPフレームワークの経験が浅いと、どのクラスがどういった役割をするのかがイマイチピンとこないケースは多いように感じます。

個人開発なら、ある程度自由にコードを書き始めて、慣れたら適切にモジュール分割していくことが良い学習になります(私もこのタイプでしたし、今も日々改善しています)。

チーム開発なら、開発者に規約という前提があるので、レビューでもコードに集中できます。
経験者がいればなお良いですね。

日本語ドキュメントが充実している

こちらにあるドキュメントがとても役に立ちます。
サンプルコードも多く掲載されているので、実装に迷うこともありません。
オフラインドキュメントも取得できます(こちらは英語です)。

デバッグバーが優秀

デバッグモードだと画面下にバーが表示され、画面表示時に実行されたクエリや変数の値、メモリ使用量や環境変数などを確認できます。
情報量がとても多く、開発中とてもお世話になります。

CLI

bakeコマンドです。
これによってControllerやModelなどのひな型(+テストケース)を作成できます。
マイグレーションも実行可能ですし、それをもとにテスト用のダミーデータの生成スクリプトも用意してくれます。
バッチ処理も書けます。

CakePHPで完結できる安心感

RubyのRuby on Rails、PythonのDjangoのように、基本的にはフレームワークの標準機能(+一部拡張機能)でカバーできるため、導入コストが大きくありません。
基本的なMVCはもちろん、APIClientやメール送信・セキュリティといったアプリケーションに必要な機能は一通り揃っており、上記ドキュメントを見れば大体解決できます。
また、コレクションやHash、テキスト処理などのユーティリティも充実しています。

Repository/Entityパターン

CakePHP3.xではRepository/Entityパターンを採用しており、DB問い合わせを行うクラス(Table)とデータを格納するクラス(Entity)は別です。
個人的にはModelになんでもかんでも突っ込むのがあまり好きでないので、これが標準なのはありがたいです。

他にも便利な機能はたくさんあります。
私も日々勉強しているので、皆さんも是非一度使ってみてください。

CakePHP3を使ったシステムのリポジトリはこちら
※PRお待ちしています。

サーバ移行とそれに伴うWordPress.comエラーのお話

お久しぶりです。
今回、本当はフレームワークの比較記事を書きたかったのですが、色々あって他のことを書きます。

まず、このブログおよびGo to Everyone!が動作するサーバを乗り換えました。
その話は追々書くとして、心機一転ブログ書くかと思ったわけです。

話は変わって、最近仕事や個人での開発で、ドキュメントをMarkdown形式で書くことが増えてきました。
HTMLより簡潔にマークアップすることができ、かつExcelのようにバイナリでもないのでバージョン管理の比較もやりやすいわけです(単純なテキスト比較で済むので)。

そんな経緯から、「ブログの記事もMarkdownで書けたらええのにな」と思い、ちょっと調べたわけです。
このブログはWordpressで運営しているのですが、すでに導入していた「Jetpack」というプラグインにその機能があったので、それを有効化しました。

で、これを使うためにはWordPress.comというところから書くことになるわけですが、ここからハマりました。

投稿・プロフィール・画像など、ほとんど見えません!!!

ブラウザの開発者ツールで確認すると、関連してそうなAPIのレスポンスがエラーになっているようです。
Wordpress.comでは、「Wordpress.com → 公開API → 当ブログ」の流れでデータを取得していますが、どうやらサーバー移転に伴いおかしなことになっていそうだったので調べました。

調べているうちに、ついにJetpackプラグインのソースコードのデバッグを始めるも、

  • プラグインは最新 → ソースコードは最新のはず
  • サーバー上での直接編集なのであまり色々できない
  • GithubのIssuesを見てもそれっぽいバグも上がっていない

とすっかりはまっていたわけですが、以下の記事で解決しました。

PHP7.1でJetpakがエラーになる件【原因と解決方法】

以前のサーバーではPHP7.0.xを利用していました。
今回の移行に伴い「PHP7.1.x使えるからこれにしておこう」とやった結果、今回の問題に遭遇したというわけです。
サーバーの管理画面からPHP7.0.xを利用するように戻すと、問題なく表示されるようになりました。
ただ、上記の記事でも原因まではわかっていないとのことだったので、これについてはもう少し調べてみます。

改めてネットの力はすごいですね。
元記事と同様、取り急ぎ同じ事象にハマっている人の手助けになればと、こちらでも取り上げました。

プログラマにおすすめする書籍・その2

以前の記事に続き、今回もいくつか紹介させていただきます。

60分でわかる!機械学習&ディープラーニング超入門

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

60分でわかる!機械学習&ディープラーニング超入門 [ 安達章浩 ]
価格:1058円(税込、送料無料) (2017/8/6時点)

 

私と同じく碁を打つ方なら記憶に新しい「Alpha碁」をはじめ、昨今何かと話題の「機械学習」。
この「機械学習」とはどのようなものなのかをわかりやすい図解を見ながら学べます。
「60分でわかる」内容なのであくまでも入門ですが、

  • どんなものかざっくりと知りたい
  • どういった製品・サービスに活用されている(できる)のか知りたい

という方にはぴったりです。

Pythonではじめる機械学習

 

こちらは完全に参考書ですね。
数学的な知識や分析についてある程度経験がある人でないと読み進めるのは難しいかもしれません。
ただ、Pythonのコード例や図式も多いですし、内容としては基礎から学んでいけるので、ある程度プログラミングの経験があれば特に問題なく読み進められるかなと思います。

Ruby on Rails 5アプリケーションプログラミング

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

Ruby on Rails 5アプリケーションプログラミング [ 山田祥寛 ]
価格:3888円(税込、送料無料) (2017/8/6時点)

 

こちらはRubyで一番有名なフレームワーク、Railsの書籍です。
Railsはコミュニティやプロジェクトが「ひとつの世界」を作りあげている気がしています(gem使ってなんでもRailsでやってやろうぜという文化はある意味狂気です)。
最新メジャーバージョンである5に対応しており、これ一冊でアプリケーション作成は問題なく進められます。
個人的には、推しエディタであるVS Codeについてコラムで触れられていたのが嬉しかったです。
CoffeeScriptって最近あまり聞きませんが、Railsをメインで使っている人は今もバリバリ使ってるんですかね…。

今回は以上です。
日進月歩(下手すればもっと早いですね)なIT業界では情報が陳腐化するのも早いので、
フレームワークやライブラリについて書かれている書籍は新しめのものを購入するべきだと思います。
ただ、言語仕様や考え方などの根底部分は基本的に変わらないので、そういった書籍はいつのものでも新しい発見がありますね。

プログラマにおすすめする書籍・その1

今回はプログラマ(もしくは目指している方)に向けて、いくつかおすすめの書籍を紹介します。
私の経験を踏まえてなのでWeb系がメインです。ご了承ください。

リーダブルコード

「コメントの書き方」「処理のわけ方」「テストのやり方」など、プログラミングするうえで基本的な考え方を学べます。
イラストにユーモアがあるのでそちらも楽しめます。
私は今年になって手に取りましたが、プログラミング初心者から経験者まで十分楽しめる内容になっていると感じました。

はじめてのCSS設計 フロントエンドエンジニアが教えるメンテナブルなCSS設計手法

フロントエンドエンジニアというか、Webサイトを作成するなら必須となるデザインまわりについて学べます。
前半は指定方法の優先順序やSMACSSなどの設計思想など基礎的な部分について紹介されています。
後半はタスクランナーGulpとSASS、EJSなどのモダンな技術を使ってサンプルサイトを作成します。
こちらも初心者~経験者まで幅広く楽しめる内容になっています。

Laravelリファレンス Web職人好みの新世代PHPフレームワーク

 

最近流行りのPHPフレームワーク、Laravelを使った開発について学べます。
こちらはある程度経験のある方、かつWeb系で開発する方が対象です。
扱っているバージョンが5.1系と少し古いですが、こちらはLTS(長期サポート)なので今から始める場合でも特に問題ありません。
一通りの機能についてコードを見ながら学べるという点はもちろん、後半にある便利なライブラリの紹介が私にはとても役立ちました。

Go言語によるWebアプリケーション開発

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

Go言語によるWebアプリケーション開発 [ マット・ライヤー ]
価格:3456円(税込、送料無料) (2017/7/26時点)

こちらは最近何かと話題の「Go言語(Golang)」について書かれています。
Go言語の特徴として、豊富な標準関数・ビルドしてしまえばどこの環境でもバイナリ1つで動作するという手軽さ・実行速度がよくあげられます。
この本はそんなGo言語でWebAPIを作成します。
WebAPIに限らず、Go言語を学ぶにあたりたくさんのノウハウがここで紹介されているので、是非手に取ってみてください。

Windows/Mac/UNIXすべてで20年動くプログラムはどう書くべきか

最後はシェルスクリプトを利用した、未来でも動作するプログラムを書くということについて学べる書籍です。
プログラミングしていると、面倒な環境構築や異なるOSへの対応などで悩まされることがあります。
OS間で標準化されたインターフェース(POSIX互換ともいいます)だけを使えば、どんなOSでも原則同じプログラムを動作させることができ(Windows10からはUbuntuが利用可能)、バージョンアップにも柔軟に対応できます。
そのためのノウハウをコマンドの意味と合わせて学べます。
正直「そこまでシェルでやるか…」と思うような部分もありましたが、「こんなコマンドあるんか」という発見も多いのでおすすめです。

いかがでしたでしょうか。
また機会があれば紹介したいと考えていますので、希望などありましたらこちらからどうぞ。

Visual Studio CodeでDjangoをはじめる

以前書いたDjangoに関する記事の閲覧数が多いので、今回は私がDjangoアプリケーションを開発する際の設定について紹介します。

Pythonのインストール

こちら
今更2系を選ぶ理由は無いので、3系の最新をダウンロード・インストールしましょう。

Visual Studio Codeのインストール

PythonはVisual StudioやIntelliJなどのIDEでも開発可能ですが、設定が楽+軽量なので私はVisual Studio Codeを利用しています。
というわけで、まずはVisual Studio Codeをインストールしましょう。

プラグイン追加

Djangoの開発をするうえで必要な以下プラグインをVisual Studio Codeに追加します。

Jinjaについてはテンプレート用です(Djangoテンプレートでもハイライトが効くようになります)。
※Django template用のプラグインもあるのですが、これは.htmlの拡張子レベルで関連付けを行ってしまうため、通常のHTMLを書くときに影響が出ますので利用していません。

プロジェクトの作成

以前の記事を参考にしてください。

Python実行ファイルの定義

Pythonで開発するにあたり、ローカルにインストールしたPythonの実行パスを定義します。
「ファイル」→「基本設定」→「設定」または「エディタ左下の歯車」→「設定」でユーザー設定ファイルを開き、以下を定義してください。
※{path/to/〇〇} にはPythonまたは関連ライブラリがインストールされているディレクトリを定義してください。

実行設定の追加(launch.json)

Pythonに限らず、Visual Studio Codeで開いたプロジェクトを実行するために「F5」キーを押すと、実行する言語を選択するエリアが表示されます(必要に応じてここで対象言語用のプラグインをインストールすることができます)。
ここで言語を選ぶと、Visual Studio Codeでは関連する実行設定ファイル(launch.json)を「プロジェクトルート/.vscode」に自動で生成してくれます。
このファイルにある「Django」の箇所を必要に応じてメンテナンスします(以下は例ですが、初期設定から基本的には変更不要です)。

${config:python.pythonPath}は先ほど設定したpythonPath、${workspaceRoot}は現在Visual Studio Codeで開いているプロジェクトのルートディレクトリを示しています。

実行

エディタ左側の虫マークを選択し、「デバッグ」という表示横のプルダウンから「Django」を選び、横向き三角ボタンを押せば実行されます。
ちなみに、上記設定でデバッグ可能なので、ブレークポイントを貼るとそこで止められますし、変数の中身も確認できます。
ただし、それらは「–noreload」が無ければできません。

なので、通常の「ファイル変更」→「リロード」という手順を踏む場合は、上記設定から「–noreload」を除外して実行することになります(この場合、エディタのデバッグコンソールにも何も出力されません)。
eclipseやIntelliJでも同様のようです。

なお、私個人が作っているものがこちらにありますので、Djangoでの開発に興味のある方は是非ご覧ください。
※PRも受け付けております。

Djangoの記事は需要がありそうなので、またそのうち書きます。