Django REST Frameworkをバックエンドに、Next.js+MUIをフロントエンドにして、Markdown形式で記事を投稿するブログを作成しました。【Part 3】

ブログ作成についてまとめました。

Django REST Framework + Next.js (MUI) + Markdownでブログを作る【Part 3】

Django REST Frameworkをバックエンドに、Next.js+MUIをフロントエンドにして、Markdown形式で記事を投稿するブログを作成しました。【Part 2】

Django REST Framework + Next.js (MUI) + Markdownでブログを作る【Part 2】

Django REST Frameworkをバックエンドに、Next.js+MUIをフロントエンドにして、Markdown形式で記事を投稿するブログを作成しました。【Part 1】

Django REST Framework + Next.js (MUI) + Markdownでブログを作る【Part 1】

Herokuのadd-onsで、画像管理サービスのCloudinaryを使って画像を保管してみました。

## はじめに
Herokuの優れている点に、多くのadd-onサービスとの連携ができることがあると私は勝手に考えています。その中でも今回利用したのは画像や動画を管理できるサービス、Cloudinaryです。画像・動画はどうしてもサイズが大きくなるのですが、Cloudinaryであれば1GBまでは無料で利用できるんです。ありがたいですよね。そこで今回はDjangoプロジェクトの画像保管先として利用するための方法についてまとめました。

## 全体の流れ
* Heroku側の設定
* Djangoプロジェクトの側の設定

## Heroku側の設定
* Herokuのadd-onは、[[ダッシュボード]](https://dashboard.heroku.com/apps/) > [Resources]タブ内に"Add-ons"という項目があり、その画面右側の「Find more add-ons」ボタンから下の画面に遷移して追加できます。Heroku Postgresを設定したことがあれば分かるかもしれませんね。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/heroku-cloudinary-setup1_clltt0">
* 今回利用するサービスは、右上の検索欄から"cloudinary"と入力すると見つかるので、表示されたアイテムをクリックしてください。
* サービスの画面に遷移すると、サービス・"Region Availability"の説明があり、その下に"Plans & Pricing"があると思います。今回は"Starter"プランを選択した状態で右横にある「Install Cloudinary」ボタンを押しましょう。
* するとダッシュボード画面に戻るので、ここで適用させたいアプリを選択し「Submit Order Form」をクリックします。
* Herokuの[ダッシュボード] > [Overview]タブに戻ると"Installed add-ons"の項目に"Cloudinary"が追加されていることが確認できます。続いて、環境変数を取得・設定する必要があるのでここをクリックして下の画像のようなCloudinaryのページにいきます。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/heroku-cloudinary-setup2_nxgqoi">
* 遷移後、トップページの画面中央部に開発言語とコードが書かれているのが確認できると思います。ここから「Python」を選択するとインストール方法と`cloud_name`, `api_key`, `api_secret`がそれぞれ表示されているのでキーと値をそれぞれ控えておき、Herokuの[ダッシュボード] > [Settings]タブにいきます
* 2つ目の項目に"Config Vars"という項目があるので、ここから「Reveal Config Vars」ボタンを押すと設定済みの環境変数と追加入力可能なフィールドが表示されます。設定済みの環境変数にはCloudinaryのURLが表示されているのが分かると思いますが、ここに先ほど控えておいた3組のキーと値をそれぞれ入力していきましょう。これでHeroku側の設定は完了です。

## Djangoプロジェクト側の設定
### パッケージインストール
* まずは"Cloudinary"のトップページに記載があったようにDjangoプロジェクトに"Cloudinary"をインストールしましょう。また、Cloudinaryのトップページには記載がなかったのですが、DjangoプロジェクトでCloudinaryを利用する際には別途`django-cloudinary-storage`と`Pillow`をインストールする必要があるのでお忘れなく。
```
$ pip install cloudinary django-cloudinary-storage pillow
```
### settings.pyファイル設定
* 続いて`settings.py`を修正していきましょう。下のソースコードのように`INSTALLED_APPS`内および静的ファイル等の記述がある画面一番下に、"Cloudinary"関連設定を追記します。#（追加）とある行が追記したコードです。
<script src="https://gitlab.com/-/snippets/2565176.js"></script>
### .envファイル設定
* 一部順番前後しますが、ローカルでの動作確認のためにも`.env`ファイルには`SECRET_KEY`や`DEBUG`に関する記述の下に3組のキー（`CLOUD_NAME`, `API_KEY`, `API_SECRET` ）と値を記述しておきます。
### models.py設定
* 次にDjangoの管理画面からCloudinaryに画像を格納するための設定をします。
<script src="https://gitlab.com/-/snippets/2565178.js"></script>
### その他ファイル設定
* `serializers.py`, `admin.py`についても設定しますが、他のモデルにおける設定と同じなので省略します。

## 画像の確認
これで設定完了です。画像を確認するためには、Djangoの管理画面から画像が格納されているデータを選択します。マスクが多く見辛くてすみませんが、下のようになっていると思います。"Currently"とある部分が現在格納されている画像のURLになっておりクリックしてみるとブラウザに画像が表示されます。その際のURLがCloudinaryの格納庫となっているわけです。ここまで記載の通り進めた場合は、"https://res.cloudinary.com/{CLOUD_NAME}/image/upload/v1/media/imgs/{img_name}"となっていると思います。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/heroku-cloudinary-setup3_y1vfzt">

## まとめ
今回CloudinaryのStarterプランを使用したわけですが、1GB超えた場合の一つ上のプランはSilver: $99/月（2023年7月時点）ということでなかなか高額なので、画像を中心としたサービスを展開する場合は別の方法を考えた方がよさそうですね。。

Herokuのadd-onsでCloudinaryを使用する方法

DjangoプロジェクトをHerokuにデプロイしました。

## はじめに
[前回の記事](http://localhost:3002/blogs/gilab-render-django)ではGitLabとRender.comを連携させる方法についてまとめました。Herokuはこれまでも何回か使っているので個人的に振り返りを含めて改めてまとめてみます。

## Herokuへのデプロイ方法
Render.comについてはGitHubに加えてGitLabもサポートしているため便利でしたが、HerokuについてはGitHubしかサポートしていません。ということでこの記事ではデプロイする方法を2種類紹介します。
1. GitHub連携（GitHubユーザー向け）
2. Gitベースデプロイメント（GitLabユーザー向け）

## 1.GitHub連携
GitHubとの連携は非常に簡単です。
* Herokuにログイン後、[ダッシュボード](https://dashboard.heroku.com/apps)から[New] > [Create new app]と進みます。
* "App name"（アプリ名）に任意の名前を入力、"region"を選択して、「Create app」ボタンで次へ進みます。※"App name"（アプリ名）に何も入力しないとランダムで名前が生成されます。
* Appが作成されると、"Deploy"タブが最初に表示されると思います。"Deploy"タブ内の上から2つ目に"Deployment method"という項目があるのでそこから「GitHub (Connect to GitHub)」を選択します。するとその下の項目に"Connect to GitHub"という項目が表示されリポジトリが検索できるので、GitHubのリポジトリ名を入力します。
* 該当のリポジトリが見つかったら「Connect」ボタンで接続しましょう。
* すると今度はその下の項目として"Automatic deploys"が表示されます。ここでbranchを選択し「Enable Automatic Deploys」を押下します。
* 自動でデプロイが走るので"Activity"タブの「View build log」からステータスを確認しましょう。下の画像のように、緑字で"Build Succeeded"とともにチェックマークとハンマーが出てきたらデプロイ完了です。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/django-heroku-deploy3_zduagl">
* "Settings"タブからスクロールダウンしてくと、"Domains"という項目とともにデプロイされた先のURLが確認できます。
* 今後はローカルからGitHubにPushする度に自動でデプロイが走るようになります。自動デプロイを解除したい場合には、再度"Deploy"タブ内の"Automatic deploys"から「Disable Automatic Settings」ボタンを押すと解除でき、手動デプロイに切り替えられます。	

## 2.Gitベースデプロイメント
こちらはHeroku CLIからHeroku Gitに直接デプロイする方法です。
* Appを作成するところまでは1.GitHub連携と同じです。"Deployment method"から「Heroku CLI」を選択すると、下画像のようにその下の項目に"Deploy using Heroku Git"という項目が表示されるので、これを参考にしつつ進めましょう。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/django-heroku-deploy4_i738rt">
* CLIから`heroku login`を実行するとHerokuの認証画面に飛ぶので、そこからログインを実行します。メールアドレス・パスワード入力後CLIに戻ります。
* その後は以下のように`heroku git:remote`でローカルリポジトリに`remote`を追加後、`git push "heroku" main`でPUSHします。
<script src="https://gitlab.com/-/snippets/2565122.js"></script>
* URLとともに`remote: Verifying deploy... done."と表示されれば、デプロイ完了です。



## 共通
1, 2どちらにしてもここでデプロイは完了していますが、URLから遷移したとてまだDjangoの管理画面は操作できないため実質まだ使えませんね。そこで管理画面にログインしてデータを入力するところまで設定しましょう。

<script src="https://gitlab.com/-/snippets/2565145.js"></script>
* HerokuにおいてShellを操作する場合には、CLIでのコマンド入力時、上の通り`$ heroku run`を先頭につけます。
* まずは`python manage.py migrate`とすることで、Djangoプロジェクトのアプリ内のマイグレーションファイルをHerokuに反映させます。
* 続いて`python manage.py createsuperuser`とCLI上で実施することでSuperuserを作成することができます。`Username`, `Email`, `Password`のうちメールアドレスは任意設定の設定項目になります。UsernameとPasswordを入力して上のコードのような記述が出て来れば完成です。後はログインして管理画面をいじっちゃってください。

## まとめ
今回紹介したのは2種類だけでしたが、他にもDockerベースでのデプロイ方法やGitLab-CI/CDを利用したものもありますので、機会があれば紹介します。

### 参考
* [Heroku - Gitを使用したデプロイ](https://devcenter.heroku.com/ja/articles/git)

DjangoプロジェクトをHerokuにデプロイする方法

脱HerokuにともないRender.comにデプロイしてみました。

## はじめに
今に始まったことではありませんが、個人開発者の味方Herokuが無料で使えなくなったことで、同様の価格帯・スペックでテスト用・POC用に利用可能なRender.comに乗り換えた方も多いのではないでしょうか？私もついに重い腰を上げてRender.comを試してみたのでデプロイまでの方法まとめておきます。

### 注意（追記）
Render.comではSSH接続・ShellはFreeプランでは利用できません。そのため、本記事によってデプロイはできても利用ができません（申し訳ありません！！）。有償に切り替えるかデプロイ前にDjangoのSuperuserを作成しておく必要があります。前者については有償利用に切り替えるだけですが、後者については本記事に記載はないので予めご了承ください。。

## デプロイまでの流れ
デプロイは以下の手順で実施していきます。

1. アカウント作成
2. 必要ファイルの作成
3. リポジトリと接続
4. デプロイ

※ちなみに、[公式ドキュメント](https://render.com/docs/deploy-django)を見るとパッケージ管理ツールに`pip`ではなく`poetry`を使っていますが、`pip`でも問題なくデプロイできました。

## 1.アカウント作成
2023年6月時点では、GitHub・GitLab・Google・Emailでのアカウント作成ができるようです。今回私はGitLabのプロジェクトをデプロイを利用したいのでGitLabを選択しました。省略しますがメール認証・パスワード設定等をしてアカウント作成完了です。

## 2.必要ファイルの作成
Render.comにデプロイするには既存ファイルの変更、新ファイルの作成が必要になります。新ファイルは全てルートディレクトリに作成します。以下、+が新ファイル、▲が変更ファイルになりますが、下の順番で作成していくとスムーズにいくと思います。
* ▲project名/settings.py
* +requirements.txt
* +build.sh
* +render.yaml


### ▲project名/settings.py
まずはsettings.pyの修正をしていきましょう。

<script src="https://gitlab.com/-/snippets/2565110.js"></script>

省略されているコードが複数箇所ありますが、変更部分は「#(追加)」とコメントアウトしている部分になります。
DBの設定部分についてはHerokuでも同様なので、Herokuから移行する場合には追記しなくでも大丈夫だと思います。
また、`WhiteNoise`はDjango REST Frameworkでは不要かもしれませんが（未検証）、公式ドキュメント通り一応設定してみています。

### +requirements.txt
次に、ローカルでインストールしたパッケージを本番環境でも利用するために、パッケージをリスト化した`requirements.txt`ファイルを作成します。

<script src="https://gitlab.com/-/snippets/2565111.js"></script>
本当はもっと多くのパッケージをインストールしていますが、紛らわしいので省略してしまっています。ただし、`settings.py`ファイル修正時に追加したパッケージ（`whitenoise`, `psycopg`, `gunicorn`等）については必ずインストールが必要です。
`requirements.txt`ファイルは以下のコマンドを実行することで作成可能です。

```
pip freeze > requirements.txt
```

### +build.sh
次に`+build.sh`ファイルを作成します。デプロイ時に実行されるコマンドを記述したファイルです。

<script src="https://gitlab.com/-/snippets/2565107.js"></script>

通常ローカルでも利用するコマンドなので説明は省略しますが、ここでは上で作成した`requirements.txt`をインストールしているのがポイントです。

### render.yaml
最後にRender.comにおける環境を設定する`render.yaml`ファイルを作成しましょう。

<script src="https://gitlab.com/-/snippets/2565109.js"></script>

ここまで上記で設定してきた内容を反映していることが分かりますね。
Herokuの場合はUSとEuropeから選択できますが、Render.comではSingaporeも選択肢にあるのが大きな違いですね。
また、上のように`envVars`に値を入力すると、デプロイ時に環境変数を手動でセットしなくても自動で設定してくれるので便利です。

## 3.リポジトリと接続
必要なファイルが作成できたら[ダッシュボード画面](https://dashboard.render.com/)にいき、下の画像のようにヘッダーにある"New"から"Web Service"を選択します。"Configure account"（画面右側中央部）からGitLabと接続しましょう。GitLabとの接続が完了したら画面中央部に接続可能なリポジトリが表示されるので、該当のプロジェクトを「Connect』ボタンをクリックして接続させます。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/gitlab-render-django1_f53brc">

## 4.デプロイ
上で「Connect」ボタンをクリックすると下のような画面に遷移します。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/gitlab-render-django2_stnfgj">

ここから"Name"に`render.yaml`ファイルで入力したプロジェクト名を転記、他の項目も必要であれば変更を加えていき（ほぼ変更不要だと思います）、ページ最下部の「Create Web Service」を押すと、下のようにデプロイが走ります（画像では途中でキャンセルしています※なお、赤い網掛け部分にはGitLabのリポジトリのパスが表示されています）。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/gitlab-render-django3_pwfsco">

下の画像のように、左ナビゲーションの"Events"から青緑色の雲マークが表示されればデプロイ完了です。あとはDjangoのSuperuserを作成して、、という流れですが、冒頭記載の通りFreeプランではShellが使えないので、よろしければこちらの[記事](https://qiita.com/kkk777/items/91a00e431d3e1d72d51e)を参考にされると良いかもしれません。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/gitlab-render-django4_ur4s9w">

## まとめ・参考
### 参考
* [Renderにデプロイ（Django）](https://qiita.com/kkk777/items/91a00e431d3e1d72d51e#django%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%9C%E3%82%8B)

GitLabとRender.comを連携させてDjangoプロジェクトをデプロイしてみた

Twitter API v2に登録して自動でツイートしてくれるbotをPythonで作ってみました。

## はじめに
個人開発で作成したアプリを手っ取り早く無料で認知拡大させるには、やっぱりTwitterですよね。とはいえ毎日ツイートを考えて投稿するのはなかなか骨が折れると思います。ということで、投稿の自動化をすべく今回はbotを作ってみました。
※本記事で利用するツールは一部利用料金がかかる可能性があります。次章で公式へのURL付きで簡単に説明しています。

## bot作成・公開の前に
今回はTwitter API v2とHerokuを使った方法をご紹介しますが、残念ながらTwitter API v2では以前利用できた機能が一部有料版の機能となったり、Herokuについては月額利用料金がかかってしまったりで、そのまま使えないかもしれませんが詳しくは公式情報参考にしつつその点だけご留意いただいた上でご覧ください。
### Twitter APIの有料化（Freeプランあり）
以前は無料版で多くの機能が使えましたが、現行の無料版では基本的には投稿・削除機能のみが利用可能で、投稿上限は1,500ツイート/月となっています。詳しくは[公式](https://developer.twitter.com/en)でご確認ください。
### Herokuの有料化（Freeプラン撤廃）
Herokuも無料で使えることから個人開発者の間で重宝されてきましたが、現在ではローエンドのプランも有料となってしまいました。こちらも詳しくは[公式](https://jp.heroku.com/pricing)をご確認ください。
### bot公開手順
ということで幸先が良いスタートではありませんが、botを公開するまでの手順については大きく以下の通りです。

* Twitter API v2への登録（１／３）
* Pythonでbotを作成（２／３）
* Herokuに公開（３／３）

今回はPythonでbotを作成しますが、Rust、PHP、JavaScript等でも作成可能です。

## bot作成
### Twitter API v2への登録（１／３）
#### Twitter APIとは
そもそも[Twitter API](https://developer.twitter.com)とは、ですが「Twitterアプリケーションを使うことなく、ツイート・いいね・リツイート等の情報を取得・投稿できるサービス」です。なお、API利用にともないv1とv2の2種類がありますが、v1は[非推奨](https://twittercommunity.com/t/deprecating-the-premium-v1-1-api/191092)となりました。また、v2についても、これまでEssential, Elevated, Academic Reseachの3種類がありましたが、こちらも非推奨となりましたのでこの記事は無料で利用可能なv2（Free）の利用について解説します。ちなみに、Freeの他にはBasicとEnterpriseがいずれも有料です。

#### アカウント作成
* 前置きが長くなりましたが、アカウント作成後はCONSUMER_KEY, CONSUMER_API_SECRET, ACCESS_TOKEN, ACCESS_TOKEN_SECRET, BEARER_TOKENが発行できるのでこれらは別途控えておいてください。
* なお、ACCESS_TOKENについては"[Read and Write](https://developer.twitter.com/en/docs/apps/app-permissions) permissions"となっていることを確認しておいてください。※これが"Read only"だとツイート投稿ができません。~前述の通りプランが変わったので、こちらの設定は不要になりました。投稿しかできないんだからそりゃそうですよね。~

### Pythonでbotを作成（２／３）
* 今回は試しにSOUL'd OUTのDiggy-moさんのアレを1日1回ツイートしてくれるbotを作ります。Pythonを使ってコードを書いていきますが、ちょうど[Tweepy](https://docs.tweepy.org/en/stable/)というライブラリがあったのでこちらを使わせてもらいましょう。楽なので。まずはライブラリインストールです。
```
pip install tweepy
```
* 続いて下の通りコードを書いていきます。一行解説始めます。
<script src="https://gitlab.com/-/snippets/2567492.js"></script>
1. (l.1)tweepyをインポートします。
2. (l.3~7)Twitter APIで発行されたキーを用意します。サンプルなので直接入力していますが、`.env`ファイル等用意しておいた方が良いと思います。
3. (l.9~15)`tweepy.Client()`にキーを入れ、`client`変数に格納します。これで認証させる感じです。
4. (l.17-19)`tweet`関数を作ります。`create_tweet`メソッドの引数に投稿したい文字列を入力します。

それでは実行してみましょう。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/twitterapi-bot1_beroig">
鳴きましたね。

### Herokuに公開（３／３）
最後に作成したPythonファイルをHerokuにデプロイします。上のようにPythonファイルを作っただけではローカルからしか投稿ないので、Herokuが提供している[Heroku Scheduler](https://elements.heroku.com/addons/scheduler)というAdd-on機能を利用して定期的にPythonファイルを実行（自動投稿）する仕組みを作りましょう。
* まずはHerokuアカウントから[Heroku Scheduler](https://elements.heroku.com/addons/scheduler)（無償）をインストールします。
* Heroku Schedulerから定期実行（Job）を設定します。下の画像中央部よりCreate jobボタンをクリックすると画面右側にモーダルが表示されるので、ここで繰り返し時間（1/10min, 1/1h or 1/day）と実行コマンドを設定します。1日1度とした場合、UTC設定となるため日本国内での実行の場合には、-9時間で調整する必要があります。
* コマンド部分にはPythonファイルの実行コマンドを入力しますが、この時点で先ほど作った`tweet_sample.py`ファイルがアクセスできる状態にしておく必要があります。そのために、HerokuとGitHubが同期されている必要がありますがその設定方法は[こちらの記事](/blogs/django-heroku-deploy)でまとめていますので別途確認ください。実行コマンドまで入力が完了したらこれで「Job」の設定は完了です。v2 Freeの投稿上限は1,500ツイート/月のため、1時間毎のツイートであれば上限値に引っかからなそうですね。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/twitterapi-bot2_jx1rfc">
* また、Twitter API利用にはCONSUMER_KEY等必要であることは2.の通りですが、Herokuへのデプロイ後は、環境変数の入力を忘れないようにしましょう。HerokuのDashboardから、[Settings]タブ > [Reveal Config Vars]ボタンで環境変数は入力可能です。

## まとめ・参考
Tweepyを使えばとても簡単にbotを作ることができますね。ただし、短いスパンで同じ内容を繰り返し投稿しようとすると、Twitter側にはねられる可能性があるようです。無料枠の範囲内でプログラム側でランダムにorユニークな投稿をする仕組みを工夫して作ってみてください。
### 参考
* [Twitter Developer Platform - Home](https://developer.twitter.com/en)
* [Heroku - Herokuの価格](https://jp.heroku.com/pricing)
* [Twitter Developer Community - Deprecating the Premium v1.1 API](https://twittercommunity.com/t/deprecating-the-premium-v1-1-api/191092)

Twitter API v2に登録して自動投稿するbotを作ってみた

ついついそれっぽく使ってしまうソレについてまとめました。

## はじめに
クラスとかモジュールとかなんとなく理解しているつもりになりがちですが、私自身恥ずかしながらいつも知ったかぶりをしてしまいます。と言うことで恥を忍んで自分用にもまとめました。

## 例文と図
本説明ですが少々概念的であるため、初学者にとってはなかなか理解しづらいと思います。そこで、下のような図と例文を作成してみました。一つ目が完成品メーカーにおける指示の記述、二つ目がPython世界における考え方の記述です。そもそもPythonはオブジェクト指向のプログラミング言語のため、各モジュール内にオブジェクトとしてクラスが格納されており、それを必要に応じて呼び出して使います。では、現実世界（目に見えるハードウェアの世界）で考えていましょう。あなたは完成品メーカーで管理職として働いているとします。完成品メーカーは部品メーカーから物を調達して、組み立て世に出すのが役割ですね。現在部品メーカーAから部品Dを調達していますが、例えば災害によりAの工場Bの操業が停止になってしまったとします。当然部品Dは安定供給が難しくなるため他のサプライヤーを探します。その際の指示は以下のようになるでしょう。
* ***部品メーカーAのB工場内C部門に問い合わせて、製造している部品Dで代用してください。***

<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/python-lpmcf1_mbgcuz">

これをPythonの世界で考えると以下の通りです。
* ***外部ライブラリAのBモジュール内にあるCクラスのDメソッド（関数）を利用してください。***

以上のように（？）実際にはこんなに丁寧に表現することはありませんが、より広い概念から狭い範囲まで構造化できると、各用語の関係性についてのイメージがつきやすいと思います。（~~例文が意味不明という意見は受け付けません。~~）続いて、各要素の説明に移ります。

## 各要素
### ライブラリ
先述の完成品メーカーの例でいう **部品メーカー** にあたります。
* 実にややこしいことに、ライブラリのことをパッケージと呼ぶこともありその逆もまた然りと両者は曖昧です。（ざっくりですが）パッケージをいくつかまとめた大きなものがライブラリだという理解で良いかなと思います。そして、そのライブラリには標準ライブラリと外部ライブラリの2つがあります。ラブライブはありません。

#### 標準ライブラリ
Pythonをインストールした時点で利用できるライブラリです。`pip`コマンドでインストールすることなく使用することができます。標準ライブラリだけでも膨大な量があるので、こちらの[Python標準ライブラリ（公式ドキュメント）](https://docs.python.org/ja/3/library/index.html)を常に参照できるようにしておくと良いですね。

<details>
<summary>Python 標準ライブラリ</summary>
<ul><li>組み込み関数<a href="https://docs.python.org/ja/3/library/functions.html">（公式ドキュメント）</a>
 
・・・<code>enumerate()</code>, <code>open()</code>, <code>print()</code>, <code>range()</code>, <code>str()</code>, etc.
</li>
<li>組み込み定数<a href="https://docs.python.org/ja/3/library/constants.html">公式ドキュメント</a>
 
・・・<code>False</code>, <code>True</code>, <code>None</code>, etc.
</li>
<li>組み込み型<a href="https://docs.python.org/ja/3/library/stdtypes.html">公式ドキュメント</a>
 
・・・ブール演算（<code>False</code>, <code>True</code>, <code>None</code>）, 比較（<code>></code>, <code><</code>, <code>==</code>）, 数値型（<code>int</code>, <code>float</code>）, etc.
</li>
<li>その他モジュール<a href="https://docs.python.org/ja/3/library/index.html">公式ドキュメント</a>
<a href="https://docs.python.org/ja/3/library/index.html">公式ドキュメント</a>
 
・・・数学（<code>math</code>, <code>random</code>, <code>statistics</code>）, ファイル・ディレクトリアクセス（<code>os.path</code>, <code>pathlib</code>）, etc. 
</li>
</ul>
</details>

#### 外部ライブラリ
Pythonのインストール後に`pip`コマンド等を使って別途インストールしてから使うことができるライブラリです。例えば、Webアプリケーションフレームワークの`Django`や機械学習ライブラリの`scikit-learn`等がそれにあたります。AIや機械学習で有名なPythonですが、このようなライブラリが一役買っています。

### パッケージ
先述の完成品メーカーの例でいう **部品メーカー** にあたります。
* モジュールを集めたディレクトリで、`__init__.py`ファイルが存在していることが特徴です。
<script src="https://gitlab.com/-/snippets/2565795.js"></script>
例えば、Djangoのディレクトリ構成の記事でも紹介しましたが各ディレクトリ（`sample_project`、`sample_app`）内にも同様にありますよね。`__init__.py`ファイル内には何も記述されていなくても大丈夫ですが、`__init__.py`ファイルによってディレクトリを **パッケージ** だと認識させることができ、そのディレクトリ内でモジュールを検索することができます。※ただし、version 3.3以降は`__init__.py`がなくてもディレクトリをパッケージと認識してくれます。
* 長々と説明しましたが、端的に言えばディレクトリです。

### モジュール
先述の完成品メーカーの例でいう **工場** にあたります。
* `.py`がついた、クラスやメソッド・関数がまとめられたファイルです。難しく考える必要はないですね。

### クラス
先述の完成品メーカーの例でいう **部門** にあたります。
* モジュール内にありメソッドや関数をまとめて記述した処理のものです。

### メソッド・関数
先述の完成品メーカーの例でいう **部品** にあたります。
いずれもクラス内の実際の処理内容で、並列で記載しましたが、厳密には違います。なお、下記の通り説明していますが、例外はあります。
* 関数・・・単独で呼び出し可能なものです。例えば、`print()`関数は引数を入れてあげればいつでも呼び出し可能ですね。
* メソッド・・・変数や値に`.（ドット）`を付け加える形式で呼び出すものです。例えば、リストから要素を取り出す`.pop()`はメソッドにあたります。

## 使用法
ということである程度違いが分かった（？）ところで、使い方についても見てみましょう。
Pythonでは次のようにモジュールをインポートして使えるようになります。上はパッケージ全部、下はパッケージの中でもモジュール指定でのインポートの方法です。モジュール指定してインポートするかどうかで、実際の呼び出し方が変わってきます。
<script src="https://gitlab.com/-/snippets/2566958.js"></script>
上の方法ではパッケージ全体をインポートするため、パッケージ内の複数のモジュールにアクセスできます。ただし、モジュール名を指定する必要があるのでコード自体は長くなります。一方で下の方法では特定のモジュールだけをインポートしますが、モジュール内の関数やクラスを直接使用できるためコードの可読性が向上します。ただし、モジュールごとにインポートを記載する必要があります。どちらの方法を取るかは都度決めると良いと思います。

## まとめ・参考
普段から使っていれば特に迷うことはありませんが、使い分けができていないとドキュメントを読むのに一苦労だと思うのでさっさと覚えてしまいましょう。

Pythonのライブラリ、パッケージ、モジュール、クラス、関数・メソッドの違い

Djangoでの開発時よく使用されるコマンドについて調べました。

## はじめに
Djangoで必ず使用するファイルと言えば？、、、`manage.py`ですよね。これが使えないと話にならないと思います。ではこのファイルを使ったコマンドはいくつ言えますか？、、、`makemigrations`, `migrate`, `runserver`もセットで覚えると思いますが、私だけでしょうか、他は使わないからすぐ忘れてしまうんですよ。山手線ゲームやったら確実に4・5人目で切れますね。そこで今回はコマンドおよびコマンドラインユーティリティの種類・使い方についてまとめました。

## コマンドラインユーティリティ
コマンドラインユーティリティはDjangoプロジェクトを実行するために必要なものです。以下の通り3種類あります。いずれも同じ役割を果たしますが、一番はじめにプロジェクトを作る際には`django-admin`を使用します。
<script src="https://gitlab.com/-/snippets/2566313.js"></script>
* `django-admin`：
 * プロジェクト作成時に使用します。
* `python3 manage.py`：
 * 最も高頻度で使用されます。
* `python3 -m django`：
 * `manage.py`に共に使用することができます。

## コマンド
ここから上記のコマンドユーティリティを使用した頻出コマンドをまとめます。
<script src="https://gitlab.com/-/snippets/2566315.js"></script>
* `$ django-admin startproject`：
 * Djangoプロジェクトを作成するためのコマンド。まさにDjangoの根幹（1）。
* `$ django-admin startapp`：
 * Djangoアプリケーションを作成するするためのコマンド。まさにDjangoの根幹（2）。
* `$ python3 manage.py collectstatic`：
 * HTMLファイル、CSSファイル、画像ファイル等のstaticファイル（静的ファイル / assets）をまとめるためのコマンド。開発環境ではDjangoが自動で管理する一方、本番環境ではこのコマンドでstaticファイルを一つのディレクトリに集めておく。`settings.py`では、STATIC_ROOT, STATIC_URL, STATICFILES_DIRS, STATICFILES_STORAGE等を別途設定する。
* `$ python3 manage.py changepassword [username]`：
 * 任意の[username]のパスワードを変更可能。
* `$ python3 manage.py createsuperuser`：
 * Djangoの管理サイトにログインし使用するための管理者ユーザーを作成するためのコマンド。ユーザー名、メールアドレス、パスワードを指定する。
* `$ python3 manage.py dumpdata`：
 * データベースの内容をバックアップ等の目的でエクスポートするためのコマンド。JSON形式、XML形式等のフォーマットを指定しアプリケーション単位、テーブル単位でエクスポート可能。
* `$ python3 manage.py help ([command name])`：
 * 困ったときはこれ。helpと入れるだけで利用可能なコマンドを出力可能。さらに、[command name]を入力すると、そのコマンドのオプション含めた使い方を教えてくれる。
* `$ python3 manage.py loaddata`：
 * dumpしたファイルをデータベースにインポートするためのコマンド。例えばJSON形式のファイルをインポートする際には、`loaddata`以降に`sample.json`という形式で指定可能。
* `$ python3 manage.py makemigrations`：
 * `models.py`で定義した内容をデータベースに反映させるための、マイグレーションファイルを作成するためのコマンド。
* `$ python3 manage.py migrate`：
 * データベースに対して、`makemigrations`で作成したマイグレーションファイルを適用するためのコマンド。
* `$ python3 manage.py runserver`：
 * 開発環境用のローカルサーバーを起動するためのコマンド。
* `$ python3 manage.py showmigrations`：
 * 作成したマイグレーションファイル一覧を表示するためのコマンド。
* `$ python3 manage.py test`：
 * 自動でテストを実行するためのコマンド。テスト内容は`startapp`実行時に自動で作成される`test.py`内に記述する。
* `$ python3 manage.py testserver`：
 * テスト用サーバーを起動するためのコマンド。

## helpを使ってできること
このようにコマンドはたーくさんあるんですが、他にもまだまだたくさんあります。実際に`help`を使ってみると、現在インストールされているライブラリに応じて、カテゴリごとに利用可能なコマンドが確認できるので見てみましょう。
<script src="https://gitlab.com/-/snippets/2566316.js"></script>
現在"django-cloudinary-storage"というパッケージが入っているので、`[cloudinary_storage]`で利用可能なコマンドが表示されていることが分かりますね。
では次に、helpの後にコマンドを追加してみます。上でも記載しましたが、`help [command name]`とすることで、各コマンドで利用可能なオプションを簡単に説明してくれます。ここでは`createsuperuser`を入力してみます。
<script src="https://gitlab.com/-/snippets/2566348.js"></script>
すると8行目以降に利用可能なオプションが表示されます。

## まとめ・参考
とりあえず"help"を使おうということだけ言っておきます。

Djangoでよく使用するコマンド

DRF環境構築時の基本的なディレクトリ構成について詳細解説しました。

## はじめに
[Django REST Framework（以降、DRF）の環境構築](/blogs/drf-setup)にてDjangoプロジェクトを作成しましたが、いきなり膨大な量のディレクトリ・ファイルができました。全ファイルを知っておかないといけないことはありませんが、「よく分からんけど動いてはる」のは気持ち悪いじゃないですか。ということでデフォルトの構成についてまとめてみました。

## ディレクトリ構成
こんな感じになっているはずです。では、「1行解説」はじめます。
 
<script src="https://gitlab.com/-/snippets/2565795.js"></script>

### ルートディレクトリおよび全体に影響するディレクトリやファイル
DjangoプロジェクトやDjangoアプリケーション以外のものをここではまとめています。
* `drf_sample/`(l.1)：
 * ルートディレクトリです。環境構築時にプロジェクト・アプリケーションを格納する箱として任意の名前を付けて用意します。
* `drf_virtual/`(l.2)：
 * 当該API専用に使用する仮想環境です。`drf_sample`作成時にデフォルトで生成されるものではありませんが、ルートディレクトリ内に作成することもできます。
* `manage.py`(l.27)：
 * Djangoプロジェクトにおいて、ローカルサーバーの起動、マイグレーションファイルの作成等、様々なコマンドを用意しているファイルです。
* `db.sqlite3`(l.28)：
 * アプリケーションに組み込まれる形で利用される簡易的なデータベースです。Djangoではデフォルトで利用可能で、設定しない限りはこのデータベースに情報が格納されます。

### Djangoプロジェクト
* `sample_project/`(l.16)：
 * `$ django-admin startproject`コマンドでDjangoプロジェクトディレクトリおよびその傘下のファイルを作成できます。自動で生成されるファイルは以下の通りです。
* `__init__.py`(l.17)：
 * このディレクトリ（`sample_project/`）がPythonのパッケージであることをPythonに認識させるためのファイルです。空のファイルで使用しません。
* `__pycache__/`(l.18)：
 * Pythonファイル実行時にコンパイルされたこのディレクトリ内のモジュールが、それぞれ`ファイル名.cpython-39.pyc`という形式でこのディレクトリ内に生成されていきます。プログラムが変更されると書き換えられるもので、文字通りキャッシュなので（消しても問題ありませんが）残しておくと実行が速くなります。
* `asgi.py`(l.23)：
 * asgiとはAsynchronous Server Gateway Interfaceの略で、Web socket等のプロトコルをサポートし、非同期通信ができるようになります。そのエンドポイントとして使用されるファイルです。
* `settings.py`(l.24)：
 * Djangoプロジェクト全体を設定するファイルです。データベース設定、認証系の設定等が可能です。
* `urls.py`(l.25)：
 * HTTPリクエストに対して、Djangoアプリケーション内のどのViewを表示するかルーティングするためのファイルです。
* `wsgi.py`(l.26)：
 * wsgiとはWeb Server Gateway Interfaceの略で、アプリケーションがWebサーバと通信するための標準のインタフェースです。そのエンドポイントとして使用されるファイルです。

### Djangoアプリケーション
* `sample_app/`(l.7)：
 * `$ django-admin startapp`コマンドでDjangoアプリケーションディレクトリおよびそれにぶら下がるファイルを作成できます。アプリケーションではデータベース定義、Viewの作成等ができます。
* `migrations/`(l.8)：
 * `$ python3 manage.py makemigrations`を実行し生成されたマイグレーションファイルが保管されるディレクトリです。
* `__init__.py`(l.10)：
 * このディレクトリ（`sample_app/`）がPythonのパッケージであることをPythonに認識させるためのファイルです。空のファイルです。
* `admin.py`(l.11)：
 * adminサイトを管理するためのファイルです。実際にデータを入力するために、`models.py`で作成したクラスをadminサイトに表示することができます。
* `apps.py`(l.12)：
 * 作成したDjangoアプリケーションの場所をDjangoプロジェクトに認識させるために設定ファイルです。※通常、`startapp`時に自動で生成されるため設定は不要です。
* `models.py`(l.13)：
 * データベースを定義するためのファイルです。データベースフィールドをまとめたモデルを作成することで、データベースにどのような情報をどのような形式で書き込むことができるか定義します。
* `tests.py`(l.14)：
 * Djangoアプリケーションにおいて、テストを実行する際にコードを記述するファイルです。
* `views.py`(l.15)：
 * HTTPリクエストに対し、表示する情報を記述するためのファイルです。

## まとめ・参考
ここまで、前記事で環境構築時に自動（+一部手動）で生成されたディレクトリおよびファイルについて、それぞれの役割を解説してきました。DRFの場合、この他にもSerializerというものが必要になるのですが、それは次の記事でまとめます。

Django REST Frameworkのディレクトリ構成

Django REST Frameworkを始める際の環境構築についてまとめました。

## はじめに
Web開発をする際のフレームワークは数多ありますが、今回はPythonのWebフレームワークであるDjangoをバックエンドに使用した方法についてまとめました。なお、本記事はDjango初学者向けとなります。

## 開発環境
* macOS 10.15 Catalina
* Python 3.9.6
* Django 4.0.2
* Django REST Framework 3.13.1
* Visual Studio Code

## 環境構築
このタイミングで使用するツールはターミナルだけで、作業自体は大きく4ステップで完了するので難しくはないと思いますが、ここからは「1行解説」やっていきます。
### ディレクトリ作成（１／４）
<script src="https://gitlab.com/-/snippets/2565791.js"></script>
1. (l.1)まずはターミナルを開いてデスクトップに移動します。今回はデスクトップにプロジェクトを作成していきます。
2. (l.2)プロジェクト全体を入れる箱として、`drf_sample`を作成します。名前は何でも大丈夫です。
3. (l.3)作成した`drf_sample`に移動します。続いて仮想環境を作成しましょう。

### 仮想環境作成（２／４）
<script src="https://gitlab.com/-/snippets/2565792.js"></script>
1. (l.1~2)仮想環境を作成する前にPythonのバージョンを確認します。2行目の通りPython 3.9.6と出てきたので、パスが通っていることが確認できましたね。※Pythonが使える環境が最低限整っていることを意味します。
2. (l.3)それでは仮想環境を作成します。今回はPythonに標準で備わっている`virtualenv`を使用して、`drf_virtual`という名前の仮想環境を作成します。仮想環境の名前は何でも大丈夫です。
3. (l.4~5)作成した仮想環境に切り替えます。5行目の通り先頭に`(drf_virtual)`が表示されていたら、仮想環境に切り替わっている状態となります。今後API作成に必要なライブラリ・パッケージはこの仮想環境内にインストールしていきます。

### ライブラリ・パッケージのインストール（３／４）
<script src="https://gitlab.com/-/snippets/2565793.js"></script>
1. (l.1~5)`Django`, `django-cors-headers`, `djangorestframework`, `djangorestframework-simplejwt`, `djoser`をそれぞれ仮想環境にインストールしていきます。ここで`===x.x.x`と、バージョン指定をしてインストールしていますが、バージョン指定しなくてもインストールは可能です。ただし、互換性を考慮しないと正しいコードを書いても実行されない可能性があるので注意してください。
※互換性については、各ライブラリ・パッケージの概要、インストール・使用方法が併記された[Python Package Index（PyPI）](https://pypi.org/)で確認してみてください。
2. (l.6)インストールが完了したら`pip freeze`とすることで、`drf_virtual`内でインストール済みのライブラリ・パッケージを確認することができます。なお、`pip freeze > requirements.txt`とすると、インストール済みのライブラリ・パッケージが書き出されたファイルがルートディレクトリ直下に生成されます。

なお、以下はDjangoを除く各ライブラリ・パッケージについて一言解説です。
* [django-cors-headers](https://pypi.org/project/django-cors-headers/)：フロントエンドとのWebAPI連携を可能にするためのパッケージ。
* [djangorestframework](https://pypi.org/project/djangorestframework/)：今回の開発の肝となるライブラリです。Djangoを利用したWebAPIの開発ができる。DRFとも略される。
* [djangorestframework-simplejwt](https://pypi.org/project/djangorestframework-simplejwt/)：DRFでJWT認証を可能にするプラグインのパッケージ。
* [djoser](https://pypi.org/project/djoser/)：DRFにおいて認証周りの機能をサポートするライブラリ。


### Djangoプロジェクト作成（４／４）
<script src="https://gitlab.com/-/snippets/2565794.js"></script>
1. (l.1)最後のステップになります。まずは`sample_project`という名前のDjangoプロジェクトを作成します。プロジェクトとは今回のAPIにおける大枠となる設定等をまとめたものです。
2. (l.2)続いて`sample_app`という名前のDjangoアプリケーションを作成します。ここでいうアプリケーションとは、データベース定義や実際のAPI作成等をするディレクトリです。
3. (l.3)プロジェクトとアプリケーションを作成したので、ベースとなる構成は完成しました。必要なファイルも勝手に生成されるので楽ですね。それでは、一旦ローカルサーバーを立ち上げてみましょう。
4. (l.4~7)ローカルサーバーを立ち上げると、4行目〜7行目の通り情報が出力されます。`http://127.0.0.1:8000/`がローカルサーバーのURLです。下のような画面がブラウザで表示されれば、OKです。`CONTROL-C`でサーバーを切ることができます。ちなみに、画面上ではバージョン情報と時間はズレまくっていますが特に影響ないので放置しておきます。
<img src="https://res.cloudinary.com/hvz4uox2m/image/upload/v1/media/img/drf-setup1_cbvgnx" />

* また、現時点で、`drf_sample`のディレクトリは以下の通りになっているはずです。全体の構成および各ディレクトリ・ファイルの役割については[Django REST Frameworkのディレクトリ構成](/articles/drf-directory)の記事で説明しています。

<script src="https://gitlab.com/-/snippets/2565795.js"></script>

## まとめ・参考
お気づきだと思いますが、Pythonが使える環境であれば、DRFの環境設定は難なくできてしまいます。次の記事から実際にコードを書いていくフェーズに入ります。

### 参考
* [PyPi](https://pypi.org/)