ゼロからのPythonとDjango

ゼロからのPythonとDjangoというようやくいい名前が付けられたのでページを作成した。このページは2021年3月31日に書き始めた。

私は長らくVC++でプログラムの開発を行っていて、ここ数年はWeb関係の仕事をメインに行っている。といっても、WordPressやConcrete5のコーディング、phpの修正などがメインで、ゴリゴリのプログラムは開発していない。

そんな中、新しいものを学んでみたいと思い、Python、Djangoというものに手を出してみた。チュートリアルなどを見ると非常に簡単に極少ないコードを書くだけでプログラム開発ができるように思え、なにかWebのアプリの開発をしてみたいと思っていたので、うってつけに思えた。

しかし、実際に試した結果としては、なかなかこれが思い通りにはならない。そのチュートリアルをたどっているだけであれば問題ないのだが、ちょっと道から逸れるような動きをすると、とたんにエラーの嵐の真っただ中に放り出され、どこまで戻ってよいのやら分からなくなってしまう。たとえば、一度完成したチュートリアルAに別なチュートリアルBの機能をミックスしてみたのだが、これは完全に動作不良になってしまった。

片手間にしかやっていない現時点での感想としては、Djangoというのは簡単にWebのプログラムが開発できるプラットフォームだが、Webの開発をずっとやってきた人が、いちいち同じコマンドを実行する、同じコードを書くのが面倒なので、フレームワークにコードを書かせたり、整合性を取らせたりということを実現してきたもの、というイメージなので、

・どこに何を書いていいかはあらかじめ決まっている。
・裏でどういうことが行われているのかは理解していないと危険。
・道を外れると後悔する。

と思った。プログラム自体にはもう四半世紀以上やっているので、一般の人に比べるとずいぶん慣れている方だと思っていて、正直言うともうちょっとサクサク進むかと思ったけど、なかなか思い通りにはいかなかった。なので、私のようなプログラマーがDjangoをやってどこに引っかかったのか、どこが分かりにくかったかということを自分のための記録としてこのページを作成しようと思った。なので、あまり他の人に読みやすいようにとかは意識していない。

一時は人に向けて記事を書いたりもしていたのだが、そうすると裏とりが大変だったりする部分も多く、いつのまにかブログも全然更新できなくなっていた。なのでこのページはとにかく自分のために、自分に起きた事実、自分での解決法の記録という目的で作成してあります。

チュートリアル１

Part 1

Writing your first Django app, part 1 | Django documentation | Django
https://docs.djangoproject.com/en/3.1/intro/tutorial01/

こちらの調査・投票のチュートリアルを実施しました。
このためにローカル環境にLinux (Ubintu18)を用意し、開発しています。

http://192.168.1.108:8080/polls/

まず

$ django-admin startproject mysite

1	$ django-admin startproject mysite

このコマンドを実行するだけで開発環境が作れてしまうというのは驚きなんですが、DjangoではDBの情報がSQLLiteという前提なのです。私の環境はMySQLを使う前提なので、必ずエラーになる。このためDBの情報は必ず修正する必要がある。修正するのはsettings.py。

つぎに初期設定では

ALLOWED_HOSTS = []

となっている。私の場合、Djangoを動かす環境はLinuxサーバーで、実際にコードを書いたりするのはWindowsなので、サーバーにアクセスしようとしてもそのホストからのアクセスが許可されていないため、エラーになる。毎回毎回腹立たしい。

ALLOWED_HOSTS = [‘*’]

としてやると、アクセスができるようになる。

ちなみに、私の環境では、Linuxにアクセスするときには以下のURLを開く。

http://192.168.1.108:8080/polls/

ちなみに、サーバー立ち上げのコマンドもこのように書いてあるけど、
実際にサーバー＝クライアントの場合にはこれでうまくいく。

$ python manage.py runserver 8080

ただ、サーバーは別になっている場合、

$ python manage.py runserver 192.168.0.108:8080

というようにIPアドレスを指定する必要がある。

URLをコントロールするのは、urls.py というファイルで、
トップレベルのURLに関しては、この場合mysite/urls.py でコントロールしている。

urlpatterns = [
  path('polls/', include('polls.urls')),
  path('admin/', admin.site.urls),
]

urlpatterns = [

path('polls/', include('polls.urls')),

path('admin/', admin.site.urls),

]

このように書くことで、アプリケーションが受け入れるのは、
polls と admin つまり、

http://192.168.1.108:8080/polls
http://192.168.1.108:8080/admin

というURLを受け入れるようになっていて、さらに、polls の下のレベルに関しては、
include(‘polls.urls’) とあるように /polls/urls.py を参照するようにコーディングする。

とりあえずここまでが Part 1

Part 2

Writing your first Django app, part 2 | Django documentation | Django
https://docs.djangoproject.com/en/3.1/intro/tutorial02/

データベースの設定がここでようやく出てくる。
最初に引っかかるはずなのだけど。

とりあえずDjangoはDBに様々な設定や情報を保存し、使用するので
Djangoから自由にアクセスするDBを設定する必要がある。

mysql の場合には、このような形でDBの設定を行う。

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'mysite',
    'USER': 'user',
    'PASSWORD': 'password!',
  }
}

DATABASES = {

'default': {

'ENGINE': 'django.db.backends.mysql',

'NAME': 'mysite',

'USER': 'user',

'PASSWORD': 'password!',

}

事前に、user というユーザーで、DBを作成しておく必要がある。

簡単に手順を示すと、

最初に MySQL に admin でログイン。
user というユーザーの作成。
MySQLからログアウト。
user というユーザーでログイン。
データベースの作成。

という感じ。

そして、次がDjangoのすごい所。

polls/model.py に保存したい情報をクラス定義として記述する。

from django.db import models


class Question(models.Model):
question_text = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')


class Choice(models.Model):
question = models.ForeignKey(Question, on_delete=models.CASCADE)
choice_text = models.CharField(max_length=200)
votes = models.IntegerField(default=0)

from django.db import models

class Question(models.Model):

question_text = models.CharField(max_length=200)

pub_date = models.DateTimeField('date published')

class Choice(models.Model):

question = models.ForeignKey(Question, on_delete=models.CASCADE)

choice_text = models.CharField(max_length=200)

votes = models.IntegerField(default=0)

—
Question というクラスと、 Choice というクラスを定義している。

Question クラス：
question_textという最大長200(Byteか？)のテキスト形式
pub_dateという名前の日付形式

Choice クラス：
questionのIDを外部キーとして持ち、
choice_textという最大長200(Byteか？)のテキスト形式
votesという数値形式

という形で定義している。

つまり

問１好きな果物は（これがquestion_text）
・りんご（これがchoice_text）
・みかん（これがchoice_text）
・ばなな（これがchoice_text）

という形で、choice_textはQuestionクラスに複数紐づけられ、さらにvotesという
数値をもつことも出来る。

そして、これを書いた後に以下のコマンドを実行すると、

$ python manage.py makemigrations polls

1	$ python manage.py makemigrations polls

Migrations for 'polls':
polls/migrations/0001_initial.py
- Create model Question
- Create model Choice

Migrations for 'polls':

polls/migrations/0001_initial.py

- Create model Question

- Create model Choice

このようにMigrationファイルというものが作成される。
このマイグレーションファイルは先ほど作成したQuestion、Choiceというクラスを
DBで扱えるように、Djangoが自動的にSQL文を作成してくれるもので、

どんなSQLが作成されたかは、

$ python manage.py sqlmigrate polls 0001

1	$ python manage.py sqlmigrate polls 0001

で確認することができる。

そして、そのDjangoが作成したMigrationファイルを反映させるには
以下のコマンドを実行する。

$ python manage.py migrate

1	$ python manage.py migrate

これを行うと、polls_question、polls_choiceという二つのテーブルが作成される。
私にとってはこのDBが自動で作成されるのがなかなかすごいと思う。
つまり、class定義の構文を解析し、

これができるということは、
このDB定義部分に書くことができる内容というのはプログラムで解析できる内容に限られていて、
解析できない内容があったり、整合性が損なわれていた場合にはエラー