完璧なモノは最初から作れないんだから、変更しやすいように組んだ方が良いよね。実際にはたいして全体には影響がほとんどないでしょ。作った後に、解析用のツールとか使ってどこにボトルネックがいるかをちゃんと実測してから性能的なチューニングをしようねと。「推測より実測」が大原則だよねと。いう話だと思うのですが、そーはいっても、ある程度の性能的な観点は最初っからやっといた方がよいと思う。ループの中でSQL毎回発行して、画面開くたびに100回クエリ発行してるとかほったらかしにしてると、結構よく出てきません?このくらいの意識は持った方が良いとは思う。早すぎる最適化はそんな感じなんだけど、原本読んでみると、それよりもぐっと来たのがあったのでそっちを書いておきたい。『誰もが「最良の」スタイルは存在しないことを覚えておくことが最も重要です。『芸術は分かんないけど、これが好きなのはわかる』って事。良いスタイルとは何だろう、悪いスタイルは何だろう。他の人が作った作品について厳しく批判するべきじゃないでしょう。みんな自分の好みがあるからね。良かれと思って指摘しててもそれはその人の好みを無意識に否定しちゃう。それって楽しくないよね。その人は自分が美しいと感じモノをその人なりに作ってるんですよ。感じたものが他の人からも有用だと思って貰えたならそれは素晴らしい事だよね。創造性の余地を残したい。何かこう、色々見てると、あーしなきゃだめ。書いてるやつは分かってないとか、デザインパターンが~、とかとか。生産性も品質も良くはなるんでしょう。つまんなくね?その型を考えた人は楽しいかもしれないけど、やらされてる方は、毎回毎回同じ感じのコード書くだけになるのではっきりいって苦痛。いう統制がとれた美しさみたいなものもあるでしょうし、そこが美しいと感じる人もいるでしょう。つまんなくね?って、自分もそういう枠組みを考える側なのですが、どうにかして、実際に作ってる人、個々人の創造性みたいなものを出せるような感じにしたいのです。自由にさせるだけじゃもちろんダメなんですけど、、、製品としてはね。確かに、ある側面では明らかにダメな実装っていうのは一杯あると思いますが、それを書いた人が、何でそう書いたのか、それが何でいいと思ったのかはちゃんと聞いてみないとですよね。創造性を出せるようにーとか自分が鼻息荒くしたところで、って感じもする。プログラム作る事を楽しんでないとやっぱダメよね。channels.」プログラマーが自分の創造性を有用なチャンネルに向ける機会を作りましょう。何かの設定とかに応じてモデルを作りたい場合はちょっと使えない。SQLを自前で書いてゴニョゴニョしてもいいんだけど、ORMは出来ればDjangoの使いたいのでどうにかしたい。いうことで、モデルを動的に作りたくなった場合。あと、動的に作ったモデルのテーブルも動的に作りたい場合についても。参考:https://code.djangoproject.com/wiki/DynamicModels※すごく古いのでちょっと微妙かも。動的にモデル作る本体は下の感じ。model普通にクラス定義するときにやってる事を、コードで書いてるだけ。attrs)models.Modelを継承したクラス定義にする。使うかというと↓の感じ。ret.objects.all()q.values()ただ、動的に作ったモデルはDBにはまだテーブル作られてないので、save()とか、objects.all()とかはもちろん動ない。テーブルをこの作ったモデル定義が作成する場合はschema-editorを使う。"\n".join(se.collected_sql)collect_sqlをTrueにすると、操作に対してのSQLがcollected_sqlのlistにたまってくので、最後に「"\n".join(se.collected_sql)」で全部取るみたいな。collect_sqlをTrueにした場合は、create_model()とかしても、SQLは発行されない。あと、作ったモデルは↓の感じで使いまわせる。ret.objects.all()q.values()「apps.all_models」がDjangoがmodel定義を全部キャッシュしてある場所。削除したい場合はここから消せばいい気がするんだけど、ちゃんと調べてないので、要調査。今のとこ使い終わった場合は↓の感じで消す。これないとapps.get_models()から消えてないあと、外部キー制約がどうもうまくいかなかった。単純なテーブルのORMやるだけなら十分。ここまで書いてて、こんなパッケージがある事に気づいた。)2019年11月28日14:23カテゴリSwaggerのアレコレSwaggerを使ってAPIのドキュメントを作る話。公式Swagger-EditorとかUIとか使えばとりあえずすぐ使える。公式のツール群は素晴らしいと思うのですが、ある程度規模が大きくなると、ちょっと無理。何でかって言うと、ソースが1ファイルだから。大きくなると行数とか普通に万超えるので。あと、Swagger-UIって1ページに全部ずらっと並べるので数が多くなってくるとますます無理。静的なHTMLファイルを作るコンバータみたいなのが欲しい。思ってたらやっぱりありますね。分割したYamlを一つのファイルにまとめるツールが必要。それをやるのに「multi-file-swagger」と「swagger-merger」があるのですが(他にもあると思うけど)、今回は「swagger-merger」を利用。npmのサイト的にこっちの方がちゃんとドキュメント書いてそうだったので。swagger-tmp.yamlYAMLが出来たらRedocでHTMLにする。swagger-tmp.yamlで、これだと修正しながらブラウザで確認できないので、なんちゃってホットリロードが出来るようにする。reload\"もろもろやったサンプルはここにあげた。ファイルの分割の書き方なんかも↑のリポジトリのsrc内参照。あと、Redocも素晴らしいのですが、若干ん?って思うところもある。左メニューの各APIへのリンクがsummryになってるのですが、ここってURLというかYAMLのタグにならないもんだろうか。)2019年11月03日01:25カテゴリその他もろもろCentOS8をVirtualBoxでインスト、ついでにMariaDBとRedisCentOS8が出てたので、VirtualBoxでとりあえずインスト。centos8のisoをDL現時点で「CentOS-8-x86_64-1905-dvd1.iso」VirtualBoxで適当に作成。新規作成で枠を作ってから、設定でストレージ⇒コントローラ:IDE⇒CDマーク押してDLしたISOを選択してから起動。インストールの流れはCentOS7と変わらずかな?ソフトの選択でサーバGUI選ぶのかワークステーション選ぶのか迷うくらい?そーいえば、.netCoreの開発みたいなアドオンが出てた。