アプリケーション

ログって業務ではよく見るけど、個人的にはあまり見ない。 何かエラーが出た時とか、操作履歴を調べたいときとか。 テキストファイルに吐き出すとgrepできるから便利ってのもあるけど、自分はデータベースに書き出してる。 勝手に圧縮してくれるし、古いログを消したいなら書き込み日付で削除のsql発行すれば一発で終わるし。 できるだけ楽をしたいなぁって思う。 あと、テーブルを使う理由は新しい順に表示させてほしいから。 テキスト表示だと、新しい書き込みは下に追加されていく。 sortかcatの逆のtacでできるけど・・・。 linuxのlogrotate設定は、bashのスクリプト使って日次バックアップの結果ログとかで使ってはいるけど、ローテート設定面倒なのであまり好かない。 世代とかサイズとか指定してく必要がある。 アプリケーションとしては、dockerコンテナで、しかもsslをnginxを通じてdjangoのコンテナを使うとログ出力がどうなるのかやってみた。 mariadbのテーブル定義 ログは、いつ、誰が、何をした、みたいなことが残ればいい。 必要なら発行したsqlとかも入れればいいけど、そこまで必要なのは業務利用の場合かなぁ。 7年ほどphpで使ってきた仕組みをdjangoで書き換えて踏襲するので、データベースのログ保管の定義は変えない。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 CREATE TABLE `GVIS_log` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id', `logPeriod` datetime DEFAULT NULL COMMENT 'ログ年月日時分秒', `logShubetsu` char(10) DEFAULT NULL COMMENT 'ログ種別', `clientIP` char(15) DEFAULT '' COMMENT 'クライアントIP', `userID` char(32) DEFAULT '' COMMENT 'ユーザID', `Sousa` varchar(100) DEFAULT '' COMMENT '操作', `Message` varchar(10000) DEFAULT NULL COMMENT 'ログメッセージ', `browser` varchar(100) DEFAULT '' COMMENT '操作', `ins_date` datetime DEFAULT NULL COMMENT 'データ作成日', `ins_user` varchar(100) DEFAULT NULL COMMENT 'データ作成ユーザ', PRIMARY KEY (`id`), KEY `GVIS_log_idx` (`logPeriod`,`userID`,`Sousa`,`Message`(255),`browser`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=66928 DEFAULT CHARSET=utf8 django用って言うと、djangoのためにid列を追加したっけ。 テーブル定義にはオートナンバのidがつかないとdjangoは処理出来ないっていうし。 ...

数値、文字、それらをchoices使いながら入力させたところから、次はアップロードボタンを設置してjpeg/png/pdfをテーブルのblob列に入れる。 これができたら、資料とかパンフレットとかを保管できる。 画像はjpegとpngぐらいしか自分では使わないから、jpeg保管で統一。 png画像はjpegに変換して保管。 画像は単に保管するだけでなく、検索結果画面の一覧表示のために80 x 45の縮小画像も作って保管してる。 blob列には、保管効率はあんまりやけど普通の文字列で扱える base64 エンコードを使ってる。 こうすると重たくなることもあるけど、html内にインライン展開して表示できる。 保全策として10MBのアップロード制限している。 実測20Mbps程度のwifi環境でamazonのfireタブレットでも閲覧・登録できる。 格納した文字列に勝手にコードがついてくれて苦労した・・・。 実際の画面の動きと、djangoに書いた内容をメモ。 画面の動き 実際はログインしてから使う資産管理の画面の一部。 ログイン機能 やデータベース(mariadb利用)の 読み書き 、入力画面の 詳細 は別のシリーズでやったので詳細は割愛。 モジュールも大きくなったので 分割 もしてるけど、追加・改善続けたらやっぱりデカくなってくなぁ。 パッケージの状態は、本当の最初の頃はdjango本体以外はこれぐらいしかなかった。 1 2 3 4 5 6 7 8 Django==3.2.7 uwsgi==2.0.19.1 django-markdownx==3.0.1 Markdown==3.3.3 Pillow==7.0.0 PyMySQL==1.0.2 matplotlib==3.4.3 numpy==1.21.2 現在pipでインストールしているモジュールは以下のとおりで、去年の年末まではdjango3、12月頃からdjangoは4に バージョンアップ した。 ...

djangoの4.0ってのが先週に出たらしい。 せめてマイナーバージョンが１つ上がって4.1まで待ちたいけど、メジャーバージョンアップの練習してみたい。 この秋あたりから3.2～3.9と使い始めてきて、冬にバージョン上げてdjangoの記述をどんなふうに変えていくのかやってみた。 元のバージョン djangoはrequirement.txtに必要コンポーネントのバージョンを書いておく。 自分用にパッケージをバージョンアップするためのメモを 最初の頃に作ってある 。 djangoのロケット画面表示をdockerコンテナで表示させてた頃に手動作成したrequirement.txtはこれだけ。 その後もmariaDB接続と円グラフ描く練習のためだけなので内容は少なかった。 1 2 3 4 5 6 Django==3.2.7 uwsgi==2.0.19.1 django-markdownx==3.0.1 Markdown==3.3.3 Pillow==7.0.0 PyMySQL バージョン上げる 業務として真面目にやるなら、先にリリースノートを読むべき。 Django 4.0 release notes | Django ドキュメント | Django docs.djangoproject.com でも今は業務じゃなくてプライベートでの練習やし、ドキュメント読むの面倒やし、読まずに問題に当たったとしてもその解決過程を楽しみたいし。 失敗したら、/code/appのフォルダをdockerの永続化領域としてtar.gzで保管してるから丸ごと戻す。 問題が出たらリリースノート読むってことで、いきなりpip実行した。 エコー結果は長いし、アップグレードは「success」ってのしかチェックしないので割愛。 以下、実際にやったこと。 アップデート必要なパッケージ一覧確認(pip3 list -o)で目視確認 エラーが出ないか目視しつつパッケージのアップグレード(pip3 install –upgrade) パッケージの依存関係チェック(pip3 check)して問題出ないか確認 パッケージの書き出し(pip3 freeze)してバージョン記述の確定内容をrequirement.txtに残す ここまででrequirement.txtはこうなった。 えらい行数増えてるなぁ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 asgiref==3.4.1 backports.zoneinfo==0.2.1 cycler==0.11.0 Django==4.0 django-markdownx==3.0.1 fonttools==4.28.4 importlib-metadata==4.9.0 kiwisolver==1.3.2 Markdown==3.3.6 matplotlib==3.5.1 numpy==1.21.4 packaging==21.3 Pillow==8.4.0 PyMySQL==1.0.2 pyparsing==3.0.6 python-dateutil==2.8.2 pytz==2021.3 six==1.16.0 sqlparse==0.4.2 supervisor==4.2.2 uWSGI==2.0.20 zipp==3.6.0 バージョン上げたときのdjango処理内の対処 バージョン上げたんやからmigrateする。 ...

前回まで で、データベースに入っている文字や数字が、きちっと画面で登録・更新できるのかそれぞれ試した。 今回の、日付でjavascript使うとこと、decimalのリストボックス化は悩んだな。 数字 普通はinteger使う。パーセンテージとかレートみたいなのを扱いたいときは、floatじゃなくdecimalを使う。 floatは誤差が出そうやから使わない。 学術に使うときはfloatのほうがいいのかもしれないけど、お金を扱う場合に誤差が出たら困る。 個数とか通し番号はmodelsの中で「IntegerField」で定義。 重量とかだったら「DecimalField」で定義。 1 2 3 4 5 6 7 kazu = models.IntegerField(verbose_name='数量',db_column='Kazu', blank=True, null=True) # Field name made lowercase. def __str__(self): return self.kazu weight = models.DecimalField(verbose_name='重量-kg',max_digits=8, decimal_places=4, blank=True, null=True) def __str__(self): return self.weight 自分はdjango起点で考えているわけじゃなく、mariadbに業務データがありき、それをdjangoにinspectさせてmodelsを自動生成させたので、型について深く考えて選んだわけじゃない。 むしろmariadbでどう入れるか考えたものをdjangoに解釈してもらった。 データを先に考えて作る。 データベースの型との対照表を書いておられる方がいてわかりやすかった。 mariadbはmysqlのところ参照させてもらった。 作者さんありがとう。 Django モデルフィールド：データベースフィールド 型対応表 #Python - Qiita qiita.com 数字の入力項目は、入力フィールドに自動で上下ボタンがつく。 ...

前回まで でデータベースにある業務データを読み書きできるようになった。 ここまで来るとソースも大きくなりがちで、viewsとmodelsがデカくなってくる。 自分の好みやけど、できるだけ１つの定義とか機能は１００行ぐらいでおさまってほしい。 modelはデータベースの列の数に依存やから、まぁしゃあないか。 できれば分割できないかって思ってたら、あります、できます、その作成メモ。 分割方法をまとめておられる方がおられた。 作者さんありがとう。 formsのことは書いてなかったけど、だいたい同じ要領でできる。 django開発で肥大化したview.py を複数ファイルに分割する方法 #Python - Qiita qiita.com Djangoでモジュールを複数ファイルで構成する #Python - Qiita qiita.com 分割対象はこのへん ⭐️の箇所を更新。まずはviewsを分割し、urls.pyを書き換えていく。 次にmodelsを分割して__init__.pyにmodel定義の一覧みたいなのを追記。 けっこうあっさりできてしまう。 今は小さいけど、formsも割る準備やっちゃう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 /code/app |--gvisDjango3 | （円グラフ等、ステータス表示のための別プログラムのため省略） |--gvisWebApp | |--__init__.py | |--__pycache__ | |--admin.py | |--apps.py | |--forms.py ⭐️4 | |--migrations | |--models.py ⭐️3 | |--tests.py | |--urls.py ⭐️2 | |--views.py ⭐️1 | |--templates/gvisWebApp | | （ログインとcrudのhtmlのため省略） |--manage.py |--requirements.txt |--templates | |--gvisDjango3 | | （円グラフ等、ステータス表示のための別htmlのため省略） |--website | | （円グラフ等、ステータス表示のための別htmlのため省略） viewsの分割 さっきのツリーにあるviewsを分割。 ...