未分類

Python Webフレームワークの選び方

PythonのWebフレームワークはいろいろありすぎて何を選べば良いかすごく迷いますね。
 
私はFlaskを2,3年使っていますが、最近FastAPIという素晴らしいものが出てきたのでこれを機に調べて見ました。
 
今回は、Pythonの有名なWebフレームワークのみを集めています。
対象は以下です。
  • Django
  • Flask
  • Bottle
  • Tornado
  • FastAPI

PythonのWebフレームワークはDjango, Pyramid, Tornado, Bottle, Flask, Falcon, graphene, websauna, sanic, Quart, responder, FastAPIなどなど、いろいろあるようです。

何がスタンダードなのというのもありますが、使うためには情報が無いと困るので、ぱっと調べて情報が出てこなかったものは除外しています。


この情報というのはドキュメントが充実しているか、チュートリアルが充実しているかというものではなく、例えばgoogleで「Python Webフレームワーク」と検索して出てきたものといった意味です。


簡単に言えば人気があるフレームワークと言えると思います。


そもそもここで出てきてくれないと選択肢に上がらないと思っていますので、どんなに素晴らしくても人気がでずに終わってしまったりすると思うんですよね。

人気度

というわけで、早速人気度合いの比較から。

以下はGoogle Trendsです。(常套手段?)

見ていただくとわかると思いますが、Djangoが頭一つ抜けているのがわかります。

続いてBottleかFlaskか。

その後にTornadoかFastAPIかといったところでしょうか。

 

リポジトリ数

GitHubのリポジトリ数というのも、人気度のパラメーターになりそうです。

比較してみましょう。

GitHubでは「このページ(Advanced search)」を使います。

Advanced searchに以下の単語。

Written in this language に 「Python」を指定します。

Django Flask Bottle Tornado FastAPI
227,377 102,654 2,233 4,534

1,721

Djangoが1位。2位がFlaskといったところですね。

FastAPIはおいといて、BottleとTornadoは人気がなさ過ぎる気が・・・。

 

Twitterでの人気度

人気があるフレームワークはTwitterでツイートされている気がしたので、人気度を測ってみました。

Twitterの人気度はどうやって測れば良いのかわかりませんが、Popularityというのが表示されるサイトを見つけたのでそちらで測定してみます。

Popularityを計れるサイト

Django Flask Bottle Tornado FastAPI
52.5 46.2 52.5 62.5

11.9

FastAPIだけなんか異様に低いですね。

そういえば、FlaskとBottleとTornadoは一般的な単語でしたね。

TwitterでFlaskを検索してみたところ、料理の画像がくっついているツイートとかが出てきました。

これは参考にならないので忘れてしまいましょう。

 

誕生年

今度はそれぞれの年齢を確認してみます。

SWは個人的に年齢が長い方が成熟していて、若いほどバグが多い(偏見?)と思っているので、誕生年は重要な要素です。

Django Flask Bottle Tornado FastAPI
2005年 2010年 2009年 2009年

2018年

それぞれ生まれた年は上記の通りです。

Djangoが最も古く、FastAPIが最も若いです。

 

バージョン履歴

誕生年と同じようにバージョン履歴も重要な指標ですよね。

それぞれのバージョンは以下の通りです。

Django Flask Bottle Tornado FastAPI
3.1 1.1.2 0.12.18 v6.0.4 0.61.1

数字が高いほど更新されているように見えますが、バージョン番号付けはルールがないに等しいのでよくわかりませんね。。。

 

tagの数

tagの数で比較してみましょう。

Django Flask Bottle Tornado FastAPI
294 31 75 60 99

回数が多いほどコミュニティが活発で、頻繁にアップデートされていると言えます。

Djangoの更新回数がすごいのがよくわかりますね。

Flaskは少ないですね。バグが少ないという考え方もできるかもしれませんが、どうなんでしょうか。

ちなみに、年齢で割ってみたら活発度合いがもうちょっとわかるかもしれません。

tag数/年齢(2020-誕生年)

Django Flask Bottle Tornado FastAPI
294/15 = 19.6 31/10 = 3.1 75/11 = 6.81… 60/11 = 5.45…

99/2 = 49.5

FastAPIの更新回数がおかしいことがわかります。

まだ2年しか経っていないにもかかわらず49.5回/年(しかも今は2020年9月!)の更新です。

FastAPIの最も古いタグ 0.1.11 のリリース日を確認したところ、 「released this on 16 Dec 2018」とありました。

2018/12/16ということは約9ヶ月しか経過していません!

年132回ペースの更新です!

素晴らしく活発だと言えると思います。コミュニティのやる気を感じられます!

時点でDjango。長くて人気があるものは強いです。

Flaskは年3回程度の更新しかないようですね。

 

それぞれのフレームワークのデータまとめ

 
ひとまずデータをまとめてみます。
上の方で比較したデータだけでなくライセンスなども含めてまとめました。

  Django Flask Bottle tornado FastAPI
アイコン (みあたらない)
開始年 2005年 2010年 2009年 2009年 2018年
GitHub https://github.com/django/django https://github.com/pallets/flask https://github.com/bottlepy/bottle https://github.com/tornadoweb/tornado https://github.com/tiangolo/fastapi
Watch 2.3k 2.3k 322 1.1k 366
Star 51.8k 51.9k 7k 19.4k 20.6k
Fork 22.4k 13.7k 1.3k 5.2k 1.4k
ライセンス BSD 3-clause license BSD 3-clause license MIT License Apache License MIT License
公式サイト https://www.djangoproject.com/ https://palletsprojects.com/p/flask/ http://bottlepy.org/docs/dev/ https://www.tornadoweb.org/en/stable/ https://fastapi.tiangolo.com/
ドキュメント https://docs.djangoproject.com/en/3.1/ https://flask.palletsprojects.com/en/1.1.x/ 同上 同上 同上
Pythonバージョン Django version Python versions 2.7 or 3.5以上 2.7 and Python3 3.5.2以上 3.6以上
1.11 2.7、3.4、3.5、3.6、3.7 (1.11.17 で追加)
2 3.4, 3.5, 3.6, 3.7
2.1 3.5, 3.6, 3.7
2.2 3.5、3.6、3.7、3.8 (2.2.8 で追加)
3.0,3.1 3.6, 3.7, 3.8
依存関係 Django==3.1.1
– asgiref [required: ~=3.2.10, installed: 3.2.10]
– pytz [required: Any, installed: 2020.1]
– sqlparse [required: >=0.2.2, installed: 0.3.1]
Flask==1.1.2
– click [required: >=5.1, installed: 7.1.2]
– itsdangerous [required: >=0.24, installed: 1.1.0]
– Jinja2 [required: >=2.10.1, installed: 2.11.2]
– MarkupSafe [required: >=0.23, installed: 1.1.1]
– Werkzeug [required: >=0.15, installed: 1.0.1]
標準ライブラリ以外無し tornado==6.0.4 fastapi==0.61.1
– pydantic [required: >=1.0.0,<2.0.0, installed: 1.6.1]
– starlette [required: ==0.13.6, installed: 0.13.6]
uvicorn==0.11.8
– click [required: ==7.*, installed: 7.1.2]
– h11 [required: >=0.8,<0.10, installed: 0.9.0]
– websockets [required: ==8.*, installed: 8.1]
Template Djangoテンプレート言語(DTL), Jinja2, カスタムテンプレート jinja2 builtin template engine, mako, jinja2,cheetah 柔軟なテンプレート言語(組み込み。独自なのか不明) なし。任意のテンプレートエンジンを利用可能。
特徴 フルスタック!(全部入り!) マイクロフレームワーク! 1ファイルで使える! ロングポーリングやWebSocketを使うのにおすすめ!  
プラットフォーム OS指定は見当たらず OS指定は見当たらず OS指定は見当たらず LinuxかBSD OS指定は見当たらず
インストール方法 pip install Django pip install Flask pip install bottle pip install tornado pip install fastapi[all]

実行速度は?

まとめた後に思い出しました!

Webページは早い方がいいらしいです。

表示されないWebページはすぐにブラウザバックしますし、必要な指標の様に見えます。

ほとんどアクセスがなければ、どれを使っても関係ない気がしますが、たくさんの人に使ってもらう(予定の)Webページを作るのに、そもそも遅いフレームワークを使っていたら悲しいことになるかもしれません。

実際にどれが早いのかは、全く同じページを作ってみるしかありませんが、世の中にはベンチマークが大好きな人がいて、定期的に計測してくれていたりします。

フレームワークにもベンチマークがないかなーと検索したところ、見つけました。

このページです。

Performance (higher is better)と書いてあるので、数値が高いほどパフォーマンスが高いんじゃないかなと推測して値を確認してみましょう。

 

ページ内検索をしたところ、以下の通りになりました。

順位 フレームワーク スコア
1 FastAPI 12,991
2 Flask 1,711
3 bottle-pypy2 1,621
4 Django 1,491
5 tornado-postgresql-raw not complate

 

FastAPIの早さが際立っています!

もうFastAPI一択でいいんじゃないでしょうか?

2-4位は横並び感。

tornadoは見つかりませんでした。

パフォーマンス測定してもらえないほどマイナーなんでしょうか・・・。

 

bottleはpypy2なので参考程度ですね。実際にはdjangoの方が早いのかもしれません。

 

 

どのフレームワークを選ぶべきか?

というわけで、いい加減どのフレームワークを選ぶか決めましょう。

 

フルスタックフレームワークが欲しい

Django一択です。

フルスタックはこれしかありません。

とりあえずなんでも入っているので、後から機能が足りないということは無いと思います。

 

1ファイルだけコピーすれば使えるのが良い

Bottleですね。

ファイルをコピーすれば使える手軽さが売りです。

若干ドキュメントが少ない気がしますが、そもそもファイルが1つなんだから動きがわからなかったらソースコード見れば良いのです。

ファイルのサイズもそれほど多くないですし、ずっとBottleを使っている人なら暗記してるんじゃないですかね。

 

早いのが欲しい

FastAPIです。

ベンチマークを見ていただければ納得いただけるかと。

また、FastAPIはASGIで動きます。

Djangoもそうですが、非同期通信に対応しているので早さという意味ではWSGIより早いのに納得できるでしょう。

難点があるとしたら、生まれてから間もないことですね。

生まれてから時間が経っていないということは、まだまだ発展途上と言うことです。

発展途上ならバグもあるでしょうし、機能も増えていくかもしれません。

大きく構文が変わるかもしれません。

ドキュメントはありますが、雄志のコードがなかなか見つからないかもしれません。(Qiitaとかね)

それを差し引いてもなかなか魅力があるフレームワークだと思います。

 

ロングポーリングやWebSocketを使いたい。

Tornadoです!と言いたいところですが、Django/Flask/FastAPIなら問題なくできると思います。

Tornadoはそもそもそのために設計されたようなので、バグがすくなさそうなのが魅力です。

 

とりあえず使い始めて拡張したい

Flaskですね。

Djangoは学習コストが重いのが特徴でもあるので、画面1枚に収まるコードで動かし始められるFlaskに軍配が上がります。

Flaskはフルスタックになれるほど豊富なライブラリがPyPIに転がっていますので、DBに接続したいならFlask-SQLAlchey、RESTAPIを作りたいならFlask-RESTFul、ログイン機能が作りたいFlask-Login、manage.pyみたいなのが作りたいFlask-Admin、WebScoketが使いたいFlask-WebSocket(Flask-uWSGI-WebScoket)のようにどんどん拡張していくことが可能です。

 

迷った、何かいいのない?

Flaskをおすすめします。

FastAPIはFlaskの後継なので、構文が似通っており、比較的容易に変更可能です。

学習コストも少なく、使えなくなってもダメージが少ないです。

また、少ないコストで必要最低限のMVC(MVVM)の知識を手に入れることができます。

ドキュメントも豊富で、雄志のソースコードもたくさん転がっています。

いいことづくめの言語と言えるでしょう。

 

 

そもそも私のおすすめはFlaskなのですが、FastAPIにすごい魅力を感じています。

また、FlaskでMVVMを学んだことで、他のフレームワーク(特にフルスタックと呼ばれるもの)を学びやすくなったと感じています。

現在はLaravelを学んでいますが、ドキュメント構成やソースコードの構成を先人が考えてくれているだけでやってることはFlaskと同じです。

FlaskはすべてのWebフレームワークで最も効率よくMVVM(MVC)を学べるフレームワークじゃないかと個人的には考えています。

とりあえず迷ったらFlaskを学んでみてください。

 

 

書籍の自炊

家にあるすべての本の電子化を行った。

以下のコードでpdfの数を数えたところ、合計は3,315だった。

 

ほとんどが漫画だが、一部ハリーポッターシリーズのようなハードカバーが含まれる。

かかった期間は、裁断機の購入履歴を調べて見たところ、驚きの7年間。

購入履歴を調べて見て意外に時間が経っているのに驚く。

そんな経ってたっけ???

 

購入した裁断機は「YG-LN」の「BA58A4 a」。

領収書によると送料込みで8,500円程度だった模様。

8,500円が未だに錆びずに使えているのはかなりコスパが良いと思う。

たぶん、当時の自炊ブログや情報サイト(2chまとめとか?)をいろいろ調べて、何が良いのか悩んだ末に購入したので、当時の偉人感謝しかない。

 

スキャナは1台目に2万円くらいした気がする棒状のものを買って後悔して、その後ScanSnap IX500(5万?6万?)を買い直して、最初からこれを買えば良かったと後悔したのを覚えている。

棒のようなスキャナ(1冊スキャンしただけで捨ててしまったので型番なんか覚えていない)は、名刺や免許証をスキャンするのは大得意だったようだ。

書籍の自炊には必須の重送検知機能がないのが致命的で、1冊スキャンするのに30分以上かかる有様だった。

重送された時にページ、前のページの下に潜り込んだりして順番がわからなくなりどうしようもなくなったのを覚えている。

同じ本を持っている友人にSkypeで順番を確認したのは良い思い出(?)だ。

 

構成

ちなみに、私の自炊構成は以下の通り。

  1. スキャナ「ScanSnap ix500」
  2. 裁断機「BA58A4 a」
  3. ix500の洗浄剤(Cleaner F1)
  4. ix500の替えローラー
  5. 書籍保存場所としてSynology DS418play
  6. HDD 3TBを2個
  7. スイッチングハブ 8個口(ネットワークが足りなくなったので)
  8. ルーター(I-O Data WN-AX2033GR2/E、ipv4遅すぎ。ipv6が必要になった)
  9. LANケーブル(10mを2本くらい?)
  10. ACタップ(コンセントが足りなくなった)

 

使用金額

すべてうろ覚えで申し訳ないが・・・

  1. 5-6万
  2. 8,500円
  3. 1,690円
  4. 7,189円
  5. 6万
  6. 1.5万×2
  7. 3,000円かな?
  8. 7,000円
  9. 4,000円?
  10. 3,000円

くらいだと思う。

合計だと 171,379円 – 184,379円

計算してみたら信じられない!

すごい金額だ!

 

それから1冊あたり10分程度の労働時間がかかっている(と思う)。

本を切って、スキャンして、終わるの待って、終わったら新しい本をセットして、スキャン終わった本をまとめて捨てて、スキャン中に他の本を切って、のような作業を延々とする必要がある。

3,315冊なので、10分×3,315とすると、33,150分かかったことになる。(ほんとぉ?)

33,150分は552.5時間。休み無く作業すれば23.02日で終わるらしい。

23日で終わる作業に7年かかったのは若干びっくりした。

ただまあ、すごい飽きるし仕方ないね・・・。

 

ま、なんにせよ、すべての本をNASに入れたのでどこでも閲覧可能になったのは意外に便利だ。

会社で漫画は読まないが、外にいるときの空き時間にとか、あの技術書のここが見たいとか、そういうのですぐに対応できるのは良い。

ついでにSynologyのNASで遊べるのもなかなか良い。

今後は本の購入を電子書籍ですませるようにできれば、家に本があふれかえることはなくなるだろう。

 

書籍の電子化をしてみて

部屋が広くなった。

本をたくさん持っている人にはお勧めしたい。

あと、本棚が不要になる。

部屋の圧迫感がなくなる上、地震が来ても怖くないのは大きい気がする。

思えば、東日本大震災が電子化を始めたきっかけだったように思う。

でかい本棚2段重ねは倒れてきそうで怖いんだよね。

 

後書き

書籍をどのように管理するか(フォルダで分けるのか、アプリ使うのか)、

バックアップをどうするか(PCに入れてUSBHDD?クラウド?)、

形式を何にするか(PDF?epub?)

など、いろいろ考えることがあって、意外に楽しかったと思う。

 

あとは電子書籍をスマホ(iphone8)で読むのがきつくなってきたので、iPadを購入できれば自炊は一段落だと思う。

年だね・・・。

 

 

 

 

Androidの画面をPCで映す方法の調査

Andoroid端末の画面を、PC側でキャプチャ(スクリーンショット撮影、できれば録画)したい。

適当に調べて見たところ、Vysorというアプリを見つけた。

Vysorは、Android側にアプリのインストールが不要で、Chromeの拡張機能であるため、簡単に導入できるとのこと。

Android側の設定は開発者モードを有効にし、USBデバッグをONにするだけで良いとのこと。

開発者モードの有効化は、(個人的な記憶を頼りにすると)、メニューの端末情報だかシステムだかの一番したにある項目を7回くらいタップすればできた様な記憶がある。

これは簡単そうだと、開発者モードをONに変更し、USBデバッグをONに変更、Chromeにアドインをインストールして実行。

なんだか時間がかかったが、無事画面を共有できた。

これは便利だとポチポチ操作していたら、「Proにアップデートしろ!」画面がでて切断・・・。

便利なのは有料なのはわかるが、これはちょっと・・・。

Proへのリンクも出てこないし、画面が切り替わると、モザイクでもかけられているかのように画面が乱れる。

これでは使えないかな・・・。

 

というけで諦めて、VysorをPCからアンインストール。

Android側のアプリもアンインストール。

 

Vysor以外はAndroidにアプリインストールが必要なので、スペック的に動かないかな。どうかな?

10年位前のAndroidなのでバージョンが足りないかもしれない・・・。

 

 

Synology DS418Play購入

VPNを使いたいので購入してみました。

 

結果としてはプロバイダがBIGLOBEでIPv6接続の場合は使えませんでした。(これから二重ルータを試してみようとは思いますが)

 

使えませんでした、では買った意味が無いので色々やってみようかと思います。

 

色々やってみるのに、パッケージを眺めていたところ、pythonを見つけたので使ってみます。

 

パッケージをインストール

 

パッケージセンターからインストールするだけなので、解説は不要

 

 

SSHを有効化

 

  1. コントロールパネルを開く
  2. 端末とSNMPをクリック
  3. ターミナルタブの「SSHサービスを有効化する。」にチェックを入れる(ポート番号は22)

 

TeraTermでログイン

 

ホスト Synology NASのIP Address(192.168.*.*)
ユーザ名 AdministratorグループのユーザID
パスフレーズ 上のパスワード

 

こんな感じでログイン可能

 

cpuinfo

 

とりあえずcpuinfoでも見てみましょう。(抜粋)

公式HPに載ってる通りですね。

 

pythonの実行

 

test.pyという名前で、以下のファイルを作成します。

 

上記のファイルは以下に置きます。

/var/services/homes/{ユーザー名}/Drive/python

 

pythonフォルダはmkdirで作成しました。

何も考えずにやりましたが、vi(vim)が使えます。

 

実行します。

 

実行できました。

 

pythonのバージョン確認

 

忘れてたのでバージョンを確認してみます。

 

Linuxらしい感じで、python2が動いていたので、python3で実行し直します。

 

これも実行できました。

python2ってprint(“aaa”)って実行できましたっけ・・・?

 

venvを作成します

 

仮想環境が使えないと不便なんで使えるか確認します。

使えました。

 

当然ながら、バージョンは同じです。

 

ファイルにパスを入れてみます

 

 

実行します。

 

問題なさそうですね。

 

あとは、pipかな?

 

pipを使ってみます

 

(なんとなく)flaskをインストールします。

 

おー、できた。

 

Flaskの実行

 

とりあえずソースコードをでっち上げます。

 

実行します。

 

ブラウザでアクセスします。

 

アクセスできました。

 

DS416Playには(というか、SynologyのNASには)調べた感じブラウザは無いので(当たり前ですが)localhost:portは使え無いと思います。

また、DSM(SynologyのOS)は、アクセスするのにポート5000を使っている様なので、Flaskの標準デバッグポートとかぶっています。

ポートを変えてあげましょう。

 

これだけ動いてくれればだいたい何でもできそうですね。

 

Windows Server で ICMPv4(ping)を許可する

コントロールパネル
-> Windowsファイアウォール
-> 詳細設定
-> 受信の規則
-> 新しい規則
-> カスタム
-> すべてのプログラム
-> プロトコルの種類[ICMPv4]
-> 次のページはそのままで次へ
-> 接続を許可する
-> ドメイン、ぷらいべーと、パブリックにチェックを入れて次へ
-> 名前は適当に設定

 

 

ASP.NET アプリケーションの移行でエラー

エラーメッセージ

 

モジュール IIS Web Core
通知 BeginRequest
ハンドラー 未定義です
エラー コード 0x80070021
構成エラー この構成セクションをこのパスで使用できません。この問題は、親レベルでセクションがロックされているときに発生します。ロック状態は既定で設定されているか (overrideModeDefault=”Deny”)、または overrideMode=”Deny” もしくは従来の allowOverride=”false” を含んだ場所タグによって明示的に設定されます。

 

解決策

 

役割の追加や機能の追加から.NET Framework 3.5.1を追加する。

 

 

戦国炎舞 -共闘バトルイベント- 復刻 剣豪からの挑戦状

嫌がらせ?の様に開催された、共闘イベントのメモです。

 

第三十九回 戦国大合戦 と同時に開催されました。

 

期間:2017/08/16(水) – 2017/08/21(月)

 

特筆することも無いので、変更点とメモくらいだけ。

 

  • 勇闘の太鼓が追加されました。
    連合員に効果があり、2回クリアするまで、獲得素材が倍になります。
    入手方法は、1回共闘クリア。
    他の連合員が使った分は加算され、消費されなかった回数は次の日に持ち越されます。
    毎日1つ入手でき、1つ使用できます。
  • 連合報酬が追加されました。
    クリア回数で報酬がもらえます。
    最後までクリアすると、そこからは200回毎にガチャ券が手に入ります。
  • 交換報酬にレジェンドガチャ券(何回でも可能)が追加。
    レートはすこぶる悪いですが、いくらでもレジェンドガチャ券を手に入れるチャンスです。
    今まで素材が余っていた人はレジェンドガチャ券に交換することで少しはねぎらわれるようになるかもしれません。

このくらいですかね。

 

太鼓が追加されたおかげで、Lv1周回がしづらくなりましたが、

代わりに沢山周回しなくてもアイテムを全部とれるようになりました。

 

ま、私はとれてませんが。

100回超くらいでお守りだいたいとれたのでかなり簡単になったと思います。

良修正ですね(^_^)