はじめに この記事は、Django Advent Calendar 2016 17日目の記事です。 Django Channelsとは Django Channels — Channels 0.17.2 documentation Channels is a project to make Django able to handle more than just plain HTTP requests, including WebSockets and HTTP2, as well as the ability to run code after a response has been sent for things like thumbnailing or background calculation. Channelsは、DjangoがWebSocketやHTTP2などの単純なHTTP

Django アプリケーションから簡単に Slack や HipChat に通知を送ることができる django-channels を公開しました. 現在, Slack, HipChat, Yo の3つのチャンネルに通知を送ることができます. 背景 最近 Hubot や Slack の Integrations など, 様々な通知をチャットに集約することが増えてきています. 国産のサービスでも Mackerel は多くのチャンネルに通知を送る機能を備えています. django-channels はシンプルなインターフェースで, 様々なチャンネルに通知を送れるようにすることを目指しています. ユーザーからの投稿があった際に通知を送るようにしたり, サーバーでエラーが発生した場合にその内容を通知するようにしたりなど, 使い方は様々です. 使い方 django-channels は Python

class Test(models.Model): text = CharField(max_length=255 blank=True, null=True) fields = JSONField(blank=True, null=True) [ { "name": "sample1", "value": "value1" }, { "name": "sample2", "value": True }, { "name": "sample3", "value": "value3", "url": "https://hogehoge.com" ]

この記事について Djangoのstaticファイル（静的ファイル）の設定がわかりずらかったので整理してみました。Djangoのバージョンは1.11。わりとバージョンによって利用方法に微妙な違いがあるようです。 staticファイル(静的ファイル)の概要 Djangoでは、アプリケーションで処理を行わない静的ファイル（例:js,css,image等）をstaticファイルと呼びます。（他のフレームワークでassetsファイルと呼ばれるものと同じです） Djangoに限らず、一般にWebアプリケーションは静的ファイルの配置について次のような指針があります。 静的ファイルはWebサーバのドキュメントルート下に配置する。 ソースコード、実行ファイルはホームディレクトリに配置する。 これにより、静的ファイルはセキィリティは低いがアプリケーションを介さないため応答速度が早く、アプリケーションは余計な

初めに 最近、「機械学習に強い」、「簡単」などの理由からPythonを選ぶ人が多いと思います。 そんな人たちがWebを書こうと思った時にぶつかるのがDjangoの壁ですよね。 （あれ、そんなことない？いやいや難しいですよね！） 僕は最初、Django Tutorialだけ日本語でやって、それ以降は全部英語の文献を読んだり、会社のコードをみて勉強をしたりしましたが、結構大変でした。 webを書きたいけど、Pythonより◯ubyの方が書きやすいから◯ubyの方がいい...となってしまわないように、これまで僕が勉強したDjangoの基本や応用を詰め込んで、Djangoを最速でマスターできるような記事を書いていきます！（3, 4記事の長さになる予定です） ＊ 最速でDjangoをマスターする part2 準備 Djangoが入っていない場合は、 でインストールできるらしいです。 僕はAnacon

前回の続きです。環境、設定等はこちらを参照してください。→ DockerによるDjango（1.11.2）の開発環境構築（Ubuntu:16.04 + Nginx + uWSGI + PostgreSQL） Django でログイン認証用アプリケーションを作成します。 アプリケーションコンテナにて、accounts アプリケーションを作成。

Django:1.10 結論から言うと、以下に記載されていました。 QuerySet API reference | Django documentation | Django https://docs.djangoproject.com/ja/1.10/ref/models/querysets/#in クエリに関しては、このページを見たらよさそう。 例えば、選択した著者の出版した本一覧を取得するクエリを生成する場合は、以下のように書きます。 def search(request): form = SearchForm(request.POST) books = None if form.is_valid(): books = Book.objects.filter(author_id__in = form.cleaned_data['author']) return render(req

この記事について Djangoのマイグレーション関連の情報を自分なりに整理しました。 バージョンは1.11です。 データベースマイグレーションとは アプリケーションで使うデータベースの定義を自動的に作成・管理する機能です。 旧来データベースに接続して直接変更を行っていた作業を、モデルから自動生成されるコードの実行で置き換えます。 ・定義変更用のＳＱＬを作成する手間がなくなる。 ・データベースがバージョン管理されるので複数人での開発作業がやりやすくなる といったメリットがあり、過去の手法に比べ作業効率が大幅に上がります。 Djangoでは1.7以降のバージョンで標準的に利用できます。 同様の機能は他のフレームワークにも存在します。 ・Ruby on Rails(ActiveRecord) ・.Net Framework (EntityFramework) ・cakephp など。 日本語の文

Django REST frameworkのバリデーション この記事は Django Advent Calendar 2017 10日目の記事です。 公式のドキュメントを読んだほうが正確じゃないかな！と思うけど、誰かの役に立てばこれ幸い １行で！ Django REST frameworkを使えばvalidationも簡単！ Django REST frameworkとは みんな大好きREST framework。 Django REST framework DjangoでRESTfulなAPIを提供するときに非常に人気のあるフレームワークです。 RESTに則ったAPIを爆速で開発できると専ら噂のアレです。 ただ名前が長いので以降ではDRF(Django REST framework)と書きます。 APIを作る上でバリデーションって重要だけど、自分で作るのは地味に面倒だし個人的にはあまりや

Djangoでクエリの実行結果として、特定のカラムのみ取得するにはvaluesが使えます 例えばこんなモデルがあるとして class Book(models.Model): title = models.CharField(max_length=100) published = models.DateField() titleだけ取得する場合は以下のように書けます。 取得されるのは、辞書のリストになります。 >>> Book.objects.values('title') [{'title': u'Clean Corder'}, {'title': u'アジャイルサムライ'}, {'title': u'ハッカーと画家'}] 値だけをリストで取得したい場合は、リスト内包表記を使ってvaluesで返された値を変換することもできますが >>> [book['title'] for book in

Djangoリファレンス本家(ver 1.11)のモデルフィールドリファレンスの説明を一覧にしたものです。なお、2017/11/15時点で日本語訳されていなかった箇所については意訳しています（内容無保証です）。 フィールドの型 Djangoのモデル定義ファイル(models.py等）内で row = models.XXXField(～） のように使用します 利用可能な ID に応じて、自動的にインクリメントする IntegerField です。通常は直接使う必要はありません; 指定しない場合は、主キーのフィールドが自動的にモデルに追加されます。Automatic primary key fields も参照してください。 フィールドの型 説明

Qiitaでは初めての記事です。 Wordpressでこれまで自分のブログを書いてました。 人工知能スタートアップ取締役 橋崎良哉のブログ http://yoshiyah.com/ 基本的には人工知能やVR/AR、IoT、チャットボットみたいなところの潮流を能動的に追いかける＆自分の脳の体操ということもあり、新規事業や新規取り組みのアイデアをひたすら考える、ということをやって記事にしています。 で、最近プログラミングを始めたので、技術系の話はQiitaで書いていければと思って初投稿。 会社でも、ビジネス側をまるっと担当していて、プログラミングについては具体的な中身を分かっていなかったということもあり、 技術ブログの書き方があんまり分かってませんｗ ゆっくり慣れていければ、という感じで進めていきます。 ということで、初稿は既存ブログの転載＋追記で。 プログラミングに関しての前回の記事はこちら

お知らせ （ちょっと古いですが）この記事の内容を使ってUdemyで入門講座作っています。 興味ある方はこちらから お知らせここまで 間違い、勘違いなどありましたら優しくご指摘ください。 Django 2.0 以上 で動作すると思います。 なぜこの記事を書くのか Djangoには強力なテンプレート言語があります。 テンプレートにデータを供給するのはViewです。 そして、それを手短にコーディングする方法も用意されています。 それが「汎用ビュー(Generic View)」です。 はるか昔は関数ベースの汎用ビューを使っていたようですが、現在は主にクラスベースのビューを使います。 現在のDjangoの和訳ドキュメントは1.4が最新ですが、クラスベース汎用ビューのドキュメントはちゃんとあります。 しかし、思ったよりもクラスベース汎用ビューを解説している記事が少なかったため、書き記そうと思いました。

はじめに 今回は「ツナキチ」というニューラルネットワークによる画像認識を用いて人間の顔が一体何％　ネコっぽいのかを調べられるWebサイトを作りました。 時間がなくてsafariではデザインが崩れてしまってます。いずれ直します！) 明示的にHerokuでデプロイしていることを示したいので、リンクを貼らさせてもらいます。 https://tunakichi.herokuapp.com/ 使ったバージョンは python : v3.6.1 django : v1.11.7 です。 コメント、いいね大歓迎です。誤字や間違いは指摘していただけると助かります。 前提 ここではすでにアプリは完成していて、いまからデプロイするぞ！という方を前提にしています。 そしてデプロイをする上で、困ったことを紹介していきます。