GraphQL学習ログ①
学習の目的
最近名前をよく聞くので知っておきたい
よく行く勉強会の主催者さんがゴリ押ししている
Subscriptionがちょっと気になるお年頃
学習方法
howtographqlのGo+gqlgenコースとreact+Apolloコースをやる予定（ReactはPrismaで躓き中)
まずはGo+gqlgenコースをやっていった。 (完全にフロントとバックエンドが同期したチュートリアルだと思ってた（違った））
始める前の前提知識
GraphQL関連
エンドポイントが１つになる。フロント側が問い合わせが楽になる。
スキーマ駆動によりフロント・バックエンドがパラレルに開発を進められ、なおかつ統合時の矛盾を減らすことができる
Go関連
- 簡単なAPIは作れる
くらいの認識でスタート
これだけしか書いてないのに疲れたので、今日はここまで。
明日以降ちゃんと書く。
公式ドキュメントをちゃんと読まない私がDjangoの静的ファイルについて理解するまで
アドベントカレンダー11日目の記事です。
はじめに
週末・深夜Pythonistaです。仕事でデータまとめるときにpandas,numpy,scipyあたりをちょこちょこする程度の人です。 趣味でDjangoを使うにあたって静的ファイルでよく躓いたので、『わからないところがわからない人』向けに、その躓きポイントと解決法をまとめられたらなと思います。 間違っている点があればご指摘いただけるとありがたいです。
ぶっちゃけると公式ドキュメントがとてつもなく親切なので、
しっかり読んで、理解して、その通り手を動かせば必ず理解しているはずの内容なのです。
Q1:そもそも静的ファイルis何？
静的ファイル？:thinking: 動かないファイルって何だよ・・・？
A1: Webの仕組みを知りましょう。
公式ドキュメント読みましょう
ものすごく乱暴に言うとCSS,JS等です。
Djangoが生成する動的なコンテンツに対して、サーバーから何も加工を加えずクライアント側に提供するファイルのことを指します。
Webサーバの仕組み：MDNリファレンス
静的ファイルという言い方自体はDjango独自の言い回し（？）のようですが、ウェブアプリケーションの仕組みがわかっていれば難なく理解できるものだと思います。
これがわからないあなた（過去の自分）はWebの仕組みを勉強しましょう。
静的ファイル (画像、JavaScript、CSS など) を管理する¶ ウェブサイトではふつう、画像や JavaScript、CSS などの追加のファイルを配信する必要があります。Django では、こうしたファイルのことを「静的ファイル (static files)」と呼んでいます。静的ファイルの管理を簡単にするために、Django は django.contrib.staticfiles を提供しています。 (Django公式ドキュメント)
ちゃんと公式ドキュメントに書いてありますね。。。
Q2:結局静的ファイルはどこに置くのが正解？
Django公式ドキュメント付属のチュートリアル・DjangoGirlsTutorial(有名なDjangoのチュートリアル）では、staticディレクトリをアプリ内に掘るように紹介されています。
polls ディレクトリの中に、 static ディレクトリを作成します。Django はそこから静的ファイルを探します。
(Django公式ドキュメント)
上記のpollsはアプリ名なので、アプリ内にディレクトリを作成するように指示しています。
静的ファイルはプロジェクトのどこに置けばいいの？ Djangoは、ビルトインの "admin" アプリにより、静的ファイルをどこで探せばいいのかわかっています。私たちがやることは、blog アプリのための静的ファイルを追加することだけです。
そのために、blogアプリの中に static というフォルダを作ります
djangogirls
```
├── blog
│ ├── migrations
│ ├── static
│ └── templates
└── mysite
```
(DjangoGirlsTutorial)
こちらも同様にアプリ内にディレクトリを作成しています。
一方で、ベストプラクティスではプロジェクト直下にstaticフォルダを置くことを推奨しています。
A2: どっちでもいい
アプリ内にstaticディレクトリを作成する場合も、以下のような構成にして名前空間を利用することがほとんどだからです。（※名前空間を使わない場合のまずい場合を番外編でご紹介します） 強いて言えば、散らばっていると個人的に見にくいので、ベストプラクティスを踏襲することをお勧めします。 併用は避けましょう。
(アプリ名)
┣static
└ (アプリ名)
┣css
┣js
Q3:本番環境css当たらない問題
Djangoアプリをデプロイしようとする者の心を折るものそれが静的ファイルだと信じています。。。
A3:Webサーバーの設定の見直しをしましょう
本番環境で静的ファイルの提供を行うのはWebサーバー側が担うことが多いと思います。 静的ファイルが一か所にまとめられているか？正しく配信の設定がなされているかを確認しましょう。
Django側で気を付けるべきは1か所に静的ファイルをまとめられているかどうかに尽きます。
静的ファイルを１か所にまとめるコマンドはpython manage.py collectstaticです。
このコマンドを叩くと開発環境下でdjango.contrib.staticfilesから見えている静的ファイルをsettings.pyで設定したSTATIC_ROOTに集められます。
しかもすでに同名のファイルがある場合はタイムスタンプを確認して新しいものを保存してくれるスグレモノ！ これを行うことで、Nginxなどの設定が楽になります。
このcollectstaticコマンド周りの公式ドキュメントは日本語化が進んでおらず英語のままなのも、公式ドキュメント斜め読み勢を陥れる一端となっているのかもしれません。。。
番外編:静的ファイルの衝突
アプリ内にstaticディレクトリを作成する場合、静的ファイルの名前の衝突に注意が必要です。 Djangoでは名前が同じ静的ファイルが存在する場合、最初に検索に引っかかった方のファイルのみ提供されます。
以下のように同じ名前の静的ファイルが存在する場合、Django側ではどちらの静的ファイルを提供すべきかがわかりません。 この場合saticfilesが見つけた最初のcssを当てることになります。
h1{
color: blue;
}
h1{
color: red;
}
なので、それぞれのテンプレートで以下のようにmain.cssを呼ぼうとしても...
{% load static %}
<link rel="stylesheet" href="{% static "main.css" %}">
{% static "main.css" %} <!-- デバッグ用 -->
<h1>App1.html<h1>
{% load static %}
<link rel="stylesheet" href="{% static "main.css" %}">
{% static "main.css" %} <!-- デバッグ用 -->
<h1>App2.html<h1>
このように片方のCSSしか当たりません。
App1はテキスト青色、App2はテキスト赤色にしたかったのに両方青色になってしまいます
こんな時はfindstaticコマンドを叩きましょう。 このコマンドを使うことで、Djangoの検索順がわかります。
$ python manage.py findstatic main.css Found 'main.css' here: C:\Users\Cuz\Desktop\Projects\static_files_sample\app1\static\main.css C:\Users\Cuz\Desktop\Projects\static_files_sample\app2\static\main.css
この時上のapp1のcssが当たり、app2のcssが当たっていないことがわかると思います。
これもまた公式ドキュメントに書いてあります
まとめ
公式ドキュメント読みましょう！読もう！いや読むんだ！ これに尽きますね。。。 改めて読むととても細かいところまで書いているので、きちんと隅から隅まで丁寧に読むことをお勧めします。
（メディアファイル関連やデプロイまでは時間が足りませんでした。。。来年こそ計画的に書くぞっ！）
明日は@skd_nwさんの『開発で使ったライブラリの話とか』です！ よろしくお願いいたします！
Django ハンズオン~環境構築編~
準備しておくもの
Python、ライブラリのインストール
エディタ類
上記の環境が構築できている方は、「プロジェクトの準備(ディレクトリ作成～Djangoのインストールまで)」の章に進んでください。
すでにインストールしているPythonのバージョンが古い場合、特にこだわりがなければ一旦古いPythonをアンインストールして、再度新しいPythonのインストールを行いましょう。
Pythonのインストール
Pythonのインストールには、下記の2通りあります。 - Anacondaを利用する方法 - Python.orgから直接ダウンロードする方法
すでにどちらかでインストールしている場合はそのPythonを使用してください。
未インストールの方は、もし機械学習など統計・科学技術領域に興味があり、Pythonをそういった領域に使用したい場合はAnaconda使ったインストールを行ってください。
ハンズオンではPython.orgのpythonを使用します。 (annacondaは統計・機械学習などには適しており環境がすぐに用意できる点優秀ですが、少し外れたことをすると環境構築で泣きを見ることになります）
インストール方法については、すでに多くの記事が書かれているので割愛します。 ただし、インストールするPythonのバージョンには気をつけてください。 Dockerを使用した環境構築の記事も見かけると思いますが、慣れていなければつまづきポイントを増やしかねないためやめたほうが賢明でしょう。
VisualStudioCodeのインストール
VisualStudioCode 略してVSCodeと記述されることが多いです。 似た製品にVisualStudioがあります。たまに混同されている方がいるので確認してください。
インストール方法はGoogle先生に「VSCode インストール」と聞いてみましょう。 Microsoftのサイトに当たればあたりです。特に導入躓くことはないかと思います。強いて上げるならPATHを通すかどうかのチェックボックスがあるので、通しておくとターミナルから一発で開くことができて便利です。
参考のQiita記事です.[ VScodeのインストール手順@Windows10]
その他は特に何もありません。インストーラを実行するだけで終わるでしょう。
拡張機能の追加
VSCodeを開くと左端に並んでいるアイコンの一番下（環境による）をクリックしましょう。
下記の拡張機能を追加します。検索する際は、Pythonと検索しても、ms-python.pythonと打ってもどちらでも構いません。 前者は今回導入する拡張機能以外にもPythonに関連する拡張機能がズラッと並びます。後者は今回導入する拡張機能のみが表示されます。
今回追加する拡張機能
プロジェクトの準備(ディレクトリ作成～Djangoのインストールまで)
どこか適当にディレクトリを作成してください。 そこに仮想環境を作成していきます。
Pythonの仮想環境作成の選択肢はいくつかありますが、今回は一番シンプルなvirtualenvを使用します。
作成したディレクトリに入り、python -m virtualenv myenvと入力します。
myenvは任意の名前で構いません、単に仮想環境の名前です。
仮想環境を作成した後のディレクトリ構造は以下の通りです。(Windowsはフォルダ構成が異なります）
(myenv)~/Project/django_handson$ tree -d -L 2
.
└── myenv
├── bin
├── include
└── lib
仮想環境を作成後(ディレクトリが作成されたことを確認してから）、以下のコマンドをたたいてください。
Mac/Linuxの場合
$ source myenv/bin/activate (myenv) $ #(myenv)という表示が出れば設定完了です。
Windowsの場合
> myenv/Scripts/Activate (myenv) > #(myenv)という表示が出れば設定完了です。
ここにDjangoをインストールしていきます。
pip install django==2.2.5と入力します。==2.2.5は省略可能ですが、今回のハンズオンではつけておいてください。
ここで環境自体にはDjangoというフレームワークは入りましたが、まだWebアプリ自体は作成されていません。 これからDjangoアプリケーションを作成していきます。
アプリケーションの作成にはdjango-adminコマンドを使用します。
コンソール上でdjango-admin startproject config .と入力しましょう。
configはプロジェクトの名前になります。configと.の間にスペースを入れることを忘れないようにしてください。（不安な方はコピペしましょう）
コマンドを入力しても何も表示されないですが、それで正解です。 作成後のディレクトリは以下のようになっているはずです。
.
├── config #追加
│ ├── __init__.py #追加
│ ├── settings.py #追加
│ ├── urls.py #追加
│ └── wsgi.py #追加
├── manage.py #追加
└── myenv
├── bin
├── include
└── lib
正しくDjangoがインストールされたかを確認するために、試しに動かしてみます。
コンソール上でpython manage.py runserverと打ってください。
Warningが出ますが、後で対処しますので気にしなくて大丈夫です。
(myenv):~/Project/django_handson$ python manage.py runserver Watching for file changes with StatReloader Performing system checks... System check identified no issues (0 silenced). You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions. Run 'python manage.py migrate' to apply them. September 28, 2019 - 17:08:34 Django version 2.2.5, using settings 'config.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
表示にもある通り、デフォルトではhttp://127.0.0.1:8000/でサーバーが上がります。 以下ような画面が表示されればインストールは成功です。
表示が確認できれば、ctrl+cでサーバーを停止してください。
ここまででDjangoのインストールは完了です。
Pythonの仮想環境ﾁｮｯﾄﾜｶﾘﾀｶｯﾀ
仮想環境とは？
ふと気になったので調べてみた。多分パスをいじってるんだろうなーって思ってたけど、改めて確認したかった。
仮想環境の作り方、使い方は書いてあるけど、結局中で何が行われてるのか気になるという人向けいるのかそんな人?
結局何してたの？
パスを書き換えていました。（予想通り）
そもそもPATHって？
プログラム（実行可能ファイル）は本来フルパスを指定しなければ実行できません。
フルパスとは、Windowsでは、C:\で始まるデータの保存場所を示す文字のことを指します。
いちいちプログラムの保存場所を覚えたり、使うたびに探すのは非効率的。 そのため、よく使うファイルの場所は一箇所にまとめておくと効率的で嬉しいですよね。 それが環境変数PATHです。
以下のコマンドを実行して出力されたものが、PATHと呼ばれているものの実体です。
(windows) > echo %PATH% (linux) > echo $PATH
当方の環境だと、以下のような感じです。 出力の結果は人によって変わります。以下ではLinuxで説明していきます。
~$ echo $PATH /opt/ThirdParty-6/platforms/linux64Gcc/gperftools-svn/bin:/opt/paraviewopenfoam56/bin:/home/cuz/OpenFOAM/cuz-6/platforms/linux64GccDPInt32Opt/bin:/opt/site/6/platforms/linux64GccDPInt32Opt/bin:/opt/openfoam6/platforms/linux64GccDPInt32Opt/bin:/opt/openfoam6/bin:/opt/openfoam6/wmake:/home/cuz/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
例えば上の環境の中の/usr/binの下のpythonを出力すると
$ ls | grep python dh_python2 dh_python3 python python2 python2.7 python3 python3-config python3.6 python3.6-config python3.6m python3.6m-config python3m python3m-config x86_64-linux-gnu-python3-config x86_64-linux-gnu-python3.6-config x86_64-linux-gnu-python3.6m-config x86_64-linux-gnu-python3m-config
さらにこの中のpython3.6のファイルのタイプを調べてやると・・・
$ file python3.6 python3.6: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=09148930900f465f0cb964452b0ac22986fae752, stripped
要するに実行可能ファイルであることがわかります。
いつも、シェル上で我々が単純にpython3と打ち込んだときに、きちんとPythonが実行されるのはPATHを通しているからなんですね。
じゃあ仮想環境は何をしてるの？
※pipenvで説明を行いますが、別の仮想環境もやってることは変わらないと思います。
仮想環境を作成すると、カレントディレクトリもしくは所定の場所に仮想環境で使用するPythonやライブラリのインストールされるディレクトリができます。
当方の環境だと、/home/.local/share/virtualenv/test-tJa6NcU0/という場所に作成されました。
そのディレクトリを開くと、下記のようになります。
.
├── bin
│ ├── activate
│ ├── activate.csh
│ ├── activate.fish
│ ├── activate.ps1
│ ├── activate.xsh
│ ├── activate_this.py
│ ├── easy_install
│ ├── easy_install-3.6
│ ├── pip
│ ├── pip3
│ ├── pip3.6
│ ├── python -> python3
│ ├── python-config
│ ├── python3
│ ├── python3.6 -> python3
│ └── wheel
├── include
│ └── python3.6m -> /usr/include/python3.6m
└── lib
└── python3.6
この中で、pipenv shellを実行すると上記のファイルのうちactivateが実行されます。
このactivateの中身を一部抜粋すると、
(略) # 仮想環境ディレクトリのPATHを環境変数にセット VIRTUAL_ENV="/home/cuz/.local/share/virtualenvs/test-tJa6NcU0" export VIRTUAL_ENV # 過去の環境変数を_OLD_VIRTUAL_PATHにセット _OLD_VIRTUAL_PATH="$PATH" # PATHの先頭に仮想環境のPATHを設定 PATH="$VIRTUAL_ENV/bin:$PATH" export PATH
ということをやっています。 PATHのところでは説明していませんでしたが、PATHは前から検索が行われ、最初に見つかった場所のファイルが呼ばれる仕組みになっています。
つまり、activate内では優先的に仮想環境ディレクトリのPythonやその他ライブラリを呼び出すように設定しているだけなのでした。
で？
と言われると何も言えないです。＼(^o^)／ とはいえ、何も考えずにただ使ってるだけよりわかって使ってる方が、何か合った時に力になる・・・と信じたい＼(^o^)／
ifortからgfortranへの移行〜Can't Open included file編~
手短に
上記のようなフォルダ構成のプロジェクトのコンパイル
root> ifort -o hoge test00/*.f90 test01/src/*.f90
だとコンパイルが通るが、
root> gfortran -o hoge test00/*.f90 test01/src/*.f90
これだと通らない。
きったないMakefileを書いて解決
環境
OS:ubuntu 18.04LTS コンパイラ:gcc 7.4.0
解決方法
件のMakefileはこちら。(Makeはずぶの素人なのでﾕﾙｼﾃ…)
hoge: test00.o test01.o
gfortran -o hoge test00.o test01.o -g
test00.o: test00/test00.f90 head00
gfortran -c test00/test00.f90 -o test00.o -g
test01.o: test01/src/test01.f90 head00 test01/head01
gfortran -c test01/src/test01.f90 -I./test01/ -I./ -o test01.o -g
原因
ifortだと依存関係は明らかにしなくても羅列するだけでよしなにやってくれているらしい
一方で、gfortranだと依存関係を1つ１つ書かないといけないらしい
ちなみに
twitterでわからんって言ってたら、つよつよFortranエンジニアの方から反応をいただきました。 近々Fotran＋CMakeで幸せになる記事を書かれるそうです。（ありがてぇ（五体投地））
Fortran90+Makefileは、各ソースの依存関係までは自分で定義しないといけないので、結局自力でやる部分が多いうえにgnuでないと使えない(Windowsに持ち出しにくい)けれど
— ねこぜせんぱい (@ijknabla) 2019年6月9日
cmakeであれば、ソースファイルをリストで書くだけで依存関係の解決までやってくれるしコンパイラ/OSに依存しないし最高。
DjangoCongress JP 2019 発表資料まとめ(仮)
謝辞
発表者の方々、カンファレンスを運営されていた方々、本当にありがとうございました。 またサイボウズ様、素晴らしい会場をありがとうございました。
DjangoCongressJP2019公式ページ
公式ページでスライドと動画をまとめてアップされたようなので、今後はこちらを確認してください。(一応まとめておきますが) Django congress JP 2019
発表資料
Djangoで静的ファイルとうまくやる話 - tell-kさん(@tell_k) - 資料
Make Query Great Again! - Nakajima Yuukiさん - 資料
現場で使える Django のセキュリティ対策 - akiyokoさん(@aki_yok) - 資料
How to build and deploy a flexible React/Django hybrid application - 沼倉健介さん、Patrick Sneepさん(Awakens Inc.) - 資料
DjangoではじめるGraphQLとフロントエンド開発の協業 - nasumさん(@tomato360) - 資料
Djangoでのメール送信 - 設定からテストまで - thinkAmiさん(@thinkAmi) - 資料
Djangoアプリのデプロイに関するプラクティス - Masashi Shibataさん(@c_bata_) - 資料
Django Girls Blogのネクストステップ 〜実務レベルへ橋渡し〜 - nikkieさん(@nikkie) - 資料
自社サービスのDjango1.3サーバを1.11(LTS)にアップグレードするまでの道のり - Toshikazu Ohashiさん(@LightTiger2505) - 資料
Authorization in Django - Hiroki Kiyoharaさん(@hirokiky) - 資料
DjangoによるWebエンジニア育成への道 - 中澤 祐一さん(@y_nakazawa1220) - 資料
どうなってるの？Djangoのトランザクション - denzowさん(@denzowill) - 資料
LT発表資料
明日から使うな！Django QuerySetアレバターン - Hayao Suzuki(@CardinalXaro) - 資料
windows10+pipenvでパスが通らない問題の解決まで
結論
pipenvとvirtualenvの衝突が問題らしい 一度pipenv,virtualenvをアンインストールしてから、pipenvを再インストールをすればいいらしい
英語読めるマンはこちらへ
症状
Pythonで仮想環境は正式にpipenvを使うことになったらしいので、インストールして使おうと思ったら、
> pipenv > 'pipenv'は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません。
解決方法
First, remove your current version of virtualenv: pip uninstall virtualenv
まず今入っているvirtualenvを消します。
> pip uninstall virtualenv
Then, remove your current version of pipenv: pip uninstall pipenv
次に、今入っているpipenvを消します。
> pip uninstall pipenv
When you are asked Proceed (y/n)? just enter y. This will give you a clean slate.
「続けますか？」と聞かれたら、yesを選択しましょう。これでクリーンな状態になります。
Finally, you can once again install pipenv and its dependencies: pip install pipenv
最後にもう一度pipenvとその依存関係をインストールして終了です。
> pip install pipenv
あとがき
pipenv入れるだけで時間かかった…
python -m pipenvなら通るけどいちいち打つのは面倒だなぁと調べだしたら沼にはまった
良く日本語ページではsite-packagesをパスに入れましょうねーって書いてあるけど、不要だった？？↓
I know this sounds the mundane, but it is actually the solution for Windows systems. You do not need to modify any of your system environment variables (please do not add site-packages to your environment variables).
なんでもないようなことを言っているように思えるかもしれないけど、これがwindowsでの解決方法なんだ。環境変数は一切触らなくていい。(site-packagesを環境変数に入れることはしないでね)
