delhi09の勉強日記

技術トピック専用のブログです。自分用のメモ書きの投稿が多いです。あくまで「勉強日記」なので記事の内容は鵜呑みにしないでください。

Git/GitHubのメールアドレス周りについて調べた

概要

Gitを使い始めるときに、最初に`git config'コマンドで以下のようにユーザー名とメールアドレスを登録する事になると思う。

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

git-scm.com

ここで登録したメールアドレスが何に使われているのかとかをちゃんと理解していなかったので調べてみることにした。

ピュアGitの場合

そもそもなぜGitにメールアドレスの設定が必要なのか

GitHubやGitLabは「Gitを扱うためのWEBアプリケーション」なので、メールアドレスが必要なのは分かる。

しかし、ピュアなGitに関しては、メールアドレスを使って認証している訳でもないし、なぜメールアドレスの設定が必要なのかというのは、そもそも疑問だった。(開発チーム内で誰がコミットしたかを一意に識別したいだけなら、ユーザー名だけ必須で設定すればよいのでは?と思っていた。)

これに関しては、以下のQuoraのQAが考える上で参考にはなったが、根拠となるような一次情報には辿り着けなかった。
www.quora.com


従って、あくまで個人的な推測だが

  • ユーザー名だけだと複数のPJに関わったときに衝突する可能性が高い。
  • 個人が既に持っているもので、一意識別子に使えそうなものというと、メールアドレスか携帯の電話番号くらいしかない。(その2択ならメアドの方がベター)
  • Gitが開発された当時は、Slackとかメールよりも便利なコミュニケーション手段はなかったはずなので、コミットの内容について問い合わせたいときに連絡先がすぐに分かった方がよい。

などの理由だったのかな?と思った。

メールアドレスが何に使われているか

git logで確認すると分かるが、設定したメールアドレスは以下のように、GitのコミットのAuthor情報として埋め込まれる事になる。

f:id:kamatimaru:20210327145731p:plain

従って、リポジトリをcloneすれば誰でもこのメールアドレスはみられるので、公開したくないメールアドレスはgitのconfigには設定するべきではない。

GitHubの場合

メールアドレスが何に使われているか

GitHubの場合は、上で説明したことに加えて、コミット情報に埋め込まれたメールアドレスと、GitHub上で認証済みのメールアドレスの照合が行われる。

GitHub上で認証していないメールアドレスがgitのconfigに設定されている状態でも、GitHub上のリポジトリにコミット&プッシュはできるが、GitHub上でコミットログをみたときに、コミットのAuthorとGitHubのアカウントが紐付いていない状態になる。

  • メールアドレスが未認証の状態

f:id:kamatimaru:20210327151928p:plain

  • メールアドレス認証後

f:id:kamatimaru:20210327151948p:plain

以下の公式ドキュメントに記載の通り、メールアドレスを追加でGitHubに認証すれば、後からでもAuthorとGitHubのアカウントを紐づけることができる。
docs.github.com

「Keep my email address private(メールアドレスをプライベートに保つ)」設定について

docs.github.com

上記の公式ドキュメントに記載の通り、GitHubの画面上からSettings → Emailで、「Keep my email address private」という項目にチェックを入れると

  • GitHub上でマージしたとき
  • GitHub上でファイルを編集&コミットしたとき

などのコミット時に使用されるAuthorのメールアドレスは、GitHubに登録したメールアドレスの代わりに、GitHubがユーザーごとに提供しているxxx@users.noreply.github.comというメールアドレスが使用される。(このメアドについては後述する。)

例えば、この設定を有効にした状態でPull Requestをマージすると、コミットログは以下のようになる。
f:id:kamatimaru:20210327154721p:plain

ただ、この設定の意味はあくまでこれだけであって、他のユーザーであっても、リポジトリをcloneしてコミットログを確認すれば、普通にローカルでのコミットのAuthorのメールアドレスは閲覧可能である。

従って、「公開したくないメールアドレスはgitのconfigには設定するべきではない」という原則は変わらない。

GitHubが提供してくれているメールアドレスについて

説明が前後したが、以下のドキュメントに記載の通り、GitHubはユーザーごとにgithub.comドメインのメールアドレスを提供してくれている。

注釈: GitHubアカウントを2017年7月18日以降に作成した場合、GitHubが提供するno-replyメールアドレスは7桁のID番号とユーザ名をID+username@users.noreply.github.comという形式にしたものになります。

docs.github.com

最初にこの説明をみたときは「7桁のID番号って何だろう?」と思ったが、先に説明した「Keep my email addresses private」の項目の説明文から自分に付与されているメールアドレスが分かる。

We’ll remove your public profile email and use 63476957+delhi09@users.noreply.github.com when 〜

また、コミットのAuthor情報に埋め込まれているメールアドレスがこのメアドであっても、GitHubはアカウント情報と紐付けてくれるので、公開してもよいメールアドレスがないという場合は、このメアドをgitのconfigに設定してもよい。
(ただ、あくまでGitHubの独自仕様なので、GitLabやBitbucketも併用している場合は、globalに設定するのは微妙かもしれない)

$ git config --global user.email 63476957+delhi09@users.noreply.github.com

※ 以下エビデンス
f:id:kamatimaru:20210327162352p:plain

f:id:kamatimaru:20210327162444p:plain

既存のコミットのメールアドレスを後から修正したいとき

既にコミットしまったコミットログのメールアドレスを後から修正したいという場合もあるかもしれない。

その場合は、filter-branchというオプションがあることを知った。

【重要】ただし、コミットログのハッシュ値が全て変わってしまうので、実行してよいかは各自の置かれた状況に応じて判断が必要である。

Gitの公式ドキュメントにも「メールアドレスの一括変更」というピンポイントな具体例とともに記載されているので、実行する場合は基本このドキュメントの通りにやればよい。

$ git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
        then
                GIT_AUTHOR_NAME="Scott Chacon";
                GIT_AUTHOR_EMAIL="schacon@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

git-scm.com

本当に個人用のリポジトリでコミッターが自分しかないなら、上記公式ドキュメントに記載のコードのif文の部分も不要で、以下のような1行を実行すればよい。

$ git filter-branch --commit-filter 'GIT_AUTHOR_NAME="Scott Chacon"; GIT_AUTHOR_EMAIL="schacon@example.com"; git commit-tree "$@";' HEAD

実行すると、コミットログの量にもよると思うが、少し実行時間がかかる。

正常終了したら、git logでコミットのAuthor情報が書き変わっていることを確認する。

最後に、コミットIDも変わっているので、git push -fで強制プッシュすればOK。

参考文献

以下の記事を参考にさせて頂きました。

taikii.net
qiita.com
ryoichi0102.hatenablog.com

『リファクタリング』読書メモ (フェーズの分離 [Splite Phase])

概要

マーティン・ファウラーの『リファクタリング』が勉強になることがたくさん書いてある素晴らしい本だったので、読んだ感想や考えたことをセクション毎などの適当な粒度でメモしていきたいと思う。

www.ohmsha.co.jp

今回は「第6章 リファクタリングはじめの一歩」の「フェーズの分離(p.160)」について書く。

「フェーズの分離」の概要

一つのコードが二つ以上の異なる処理を行っている場合には、二つ以上の「順次処理ステップ」に分解するとよいということが書かれている。
※ 「順次処理ステップ」というのは、本書のサンプルコードをみた限り、事実上、関数のことだと考えて良さそうである。

加えて、処理を直列に分割するということは、前の処理のアウトプットを次の処理のインプットとして渡す必要があるということなので、「中間データ構造」を定義・導入する必要があるということも書かれている。

感想

技術的に難しいことは何も書かれていないし、ある程度プログラミング経験がある人であれば、このリファクタリング手法を使っていると意識していなくても、自然とやっている事が多いんじゃないかと思った。

あとは、設計書を作成するときに、アクティビティ図を書いたり、文章で書くにしても

1. xxxの処理を行う。
2. yyyの処理を行う。

のように処理をグルーピングしてNoを付けて書いたりすることが多かったが、これもやっていることは処理を意味内容ごとに分割するということなので、「フェーズの分離」という考え方をしていたのだと思う。

ただ、経験則でなんとなくやるのではなくて、「今、自分はフェーズの分離をしているのだな」と意識しながら作業した方がもちろん良いので、そういう意味ではリファクタリングの1技法として体系的に学びなおせてよかった。

加えて、処理を関数に分割する際に、副作用のある処理をなるべく特定の関数に閉じ込められるように意識すると、ユニットテストも書きやすいコードになるんだろうなと思った。

『リファクタリング』読書メモ (問い合わせと更新の分離 [Separate Query from Modifier])

概要

マーティン・ファウラーの『リファクタリング』が勉強になることがたくさん書いてある素晴らしい本だったので、読んだ感想や考えたことをセクション毎などの適当な粒度でメモしていきたいと思う。

www.ohmsha.co.jp

今回は「第11章 APIリファクタリング」の「問い合わせと更新の分離(p.314)」について書く。

「問い合わせと更新の分離」の概要

関数(API)を実装する際に、副作用がある関数とない関数は明確に分離するべきという主張が書かれている。
また。 そうすることで何が嬉しいのかというメリットも記載されている。

感想

なるほどと思った箇所としては、「副作用がある関数とない関数の分離」に関して、

値を返す関数は、観察可能な副作用を持ってはならないというルールを取り入れるべき

と本セクションでファウラーは主張していることである。
※ 「観察可能な」という言葉には重要な意味が込められているのだが、それはここでは話題にしない。

上記の主張は、裏を返すと「副作用のある関数では戻り値を返してはいけない(=void型にしなければならない)」と言っていることになり、単に「副作用がある関数とない関数は分けるべき」というやや漠然とした主張よりも、より厳密で踏み込んだ定義だなと思った。

というのは、単に「副作用がある関数とない関数は分けるべき」という主張からは、「副作用のある関数では戻り値を返してはいけない」ところまでは、少なくとも言葉上からは、読み取れないからである。(そういう思いも込められているのかもしれないが)

たしかに、単に「副作用がある関数とない関数は分離しましょう」だと漠然としていて、人によって解釈が違ったり、「この程度は許容範囲」の考え方が違ったりしそうなので、「副作用のある関数では戻り値を返してはいけない」という言葉にした方が、やるべきこと明確になるし自分でコーディングする際の指針としても適用しやすくなるので良さそうだなと思った。
※ ただ、少し疑問に思ったことはあって、それは「疑問」の項に書いた。

また、完全に別の感想として、最近、アーキテクチャ設計の議論ではCQRS(コマンドクエリ責務分離)の話題をよく耳にするが、関数を1つ作成するというもっと小さいレベルでも、こういうことは原則として意識するべきなんだろうなと思った。

疑問

「副作用のある関数では戻り値を返してはいけない」という指針は基本的には良いなと思ったものの、例えば「RDBに新しくデータを作成(INSERT)する場合」はどうなんだろう?と思った。

というのは、この場合、戻り値で自動採番されたIDを取得しないと、アプリケーション側で新規作成されたデータを追跡できなくなってしまうからである。

もちろん、RDBのAUTOINCREMENT機能を使わずに主キーの値をアプリケーション側で生成したり、自動採番の仕組みを採番テーブルを作って自前で実装したりすれば、戻り値で主キーを返す必要はなくなるかもしれないが、そこまでこの原則を徹底することにメリットはあるんだろうか?というのは少し疑問に思った。

ファウラー自身も

私は「値を返す関数は、観察可能な副作用を持ってはならないという」という原則を絶対的なルールにすることについて(何についてもそうですが)100%賛成ではありませんが、多くの場合はこのルールに従うようにしています。

と書いていたので、「100%賛成ではない」の部分はもしかしたらこの辺りなのかな?と思った。

Pythonでテキストファイルの読み込み・書き込みを1行で行う(pathlibを使う方法)

以下のようにpathlibを使うと、Pythonでも1行でテキストファイルの読み込み・書き込みを行うことができることを知った。

  • 読み込み
from pathlib import Path
text = Path("/path/to/fizz.txt").read_text(encoding="utf-8")
  • 書き込み
from pathlib import Path
Path("/path/to/buzz.txt").write_text("hoge", encoding="utf-8")

引数の種類・意味もopenと同じとのことである。

  • 公式ドキュメント

pathlib --- オブジェクト指向のファイルシステムパス — Python 3.9.2 ドキュメント

背景

PHPではfile_get_contentsfile_put_contentsという関数を使って一行でファイルの読み込み・書き込みができたので、ちょっとしたスクリプトでファイルを扱うときに便利だった。

PHP: file_get_contents - Manual
PHP: file_put_contents - Manual

Pythonでファイルの読み込み・書き込みを行うときは、これまではwithブロックでopenを使う方法しか知らなかったので、1行で書く方法はないのかな?とずっと思っていた。

pathlibを使うと1行で書けることを知った。

数年ぶりにリーダブルコードを読んだ

概要

数年ぶりにリーダブルコードを読んだ。

www.amazon.co.jp

前から順番にガッツリ読んだ訳ではなくて、パラパラ流し読みしつつ、引っかかったトピックを重点的に読んだ。

前回読んだのは、恐らくもう5年以上前で、まだ就職する前で大学生でアルバイトでエンジニアをやっていた頃だったと記憶している。

当時はあまりピンとこなくて、正直、一般的に高評価されているほど価値のある本だと思えなかったのだけれど、今になって読み直してみたらすごく貴重なことが色々書いてある本だということに気づいた。(この辺の評価が変わった理由についての考察は最後に書いた)

まずは以下に読み直した感想を書いていきたいと思う。

本書の全体に通底する考え方(だと思ったこと)

以下の2つは本書を読む上で、常に心に留めておきたい大事な考え方だと思った。

  1. 一貫性のあるスタイルは「正しい」スタイルよりも大切
  2. 「やりすぎ」はよくない

1.は「4章 美しさ」(p53)に出てくる言葉で、2.は「10章 無関係の下位問題を抽出する」(p140)と「14章 テストと読みやすさ」(p195)に出てくる言葉である。

本書はコーディングに関する良いプラクティスをまとめた本だが、上記の2つは常に心に留めた上で読む必要があるのではないかと思った。

(『リーダブルコード』に限らず、プログラミングの良いプラクティス集的な本を読むとき及び実践するときに大事な考え方だと思う。)

「1.一貫性のあるスタイルは「正しい」スタイルよりも大切」について

この言葉は、個人的なコードの美しさの嗜好よりも、プロジェクトの規約に従う方が重要であるという文脈で出てくる。

私はこの考え方の大切さは、コーディングスタイルの問題に限らないと思う。

担当者によって色々なコーディングスタイルや設計・実装方針が入り混じってしまうよりも、コード全体が、コードの読み手にとって、メンタルモデルを構築しやすくなっていることの方が遥かに重要だと思う。(例えそれが良いプラクティスであったとしても)

(話が逸れるが、「メンタルモデル」という言葉については、ちょっと前に読んだ以下の記事がとても勉強になったので、「メンタルモデル」っていう概念いいなと思って適切かは分からないが使ってみた。)
techlife.cookpad.com

エンジニアをやっていると、「さすがにこれは直したいな」と思うこともあると思うが、時にはムズムズしても我慢することも大事なんだろうなと思う。

「「やりすぎ」はよくない」について

この言葉は、「10章 無関係の下位問題を抽出する」では、1つの関数の処理が大きくなりすぎた場合に、複数の関数に分割するのは良いことだが、分割しすぎるとかえって読みづらくなってしまうという文脈で出てくる。

私自身、関数やクラスを分割しすぎた結果、1つのロジックを読むのにファイルの上下やファイル間を行ったり来たりしなければならなくなって、かえって読みづらくしてしまうとかはよくやってしまう。
(実装している本人はその時には気づかないが、後から自分のコードを読むと読みづらいなと感じたり、人からレビューで指摘されたりする。)

やはり、関数やクラスの分割に限らず、ソースコードの規模やプロジェクトの目的によって、適切な程度というのはあるはずなので、やり過ぎればよいというものではないと思う。
(「適切な程度」を体で覚えたり、もしくは指標化したりするのが難しいのだろうが)

個人的に重要だなと思ったトピック

以下では、個人的に重要だなと思ったトピックのいくつかに関して、読みながら考えたことや感想を書いていく。

4.6「宣言をブロックにまとめる」、4.7「コードを段落に分割する」(p51)

ある時期から、コードを書く時に、

  • 行と行の間は空けるべきなのか
  • 空けるべきだとしたら、どこで空けるのがよいのか

ということで、悩むようになった。

ただ、「こういう箇所で空白行を入れましょう」というような一般的な指針はあまり存在しないので、なんとなく「ここは処理の区切り目だから空白行を入れておこうかな?」というように、モヤモヤしながらも感覚的にやっていた。

改めて本書を再読したら、「こういう場面では空白行を入れてコードをグルーピングするといいですよ」っていう指針がちゃんと書いてあることに気づいた。

7.1 条件式の並び順(p84)

このトピックでは

if (length >= 10)

if (10 <= length)

ではどちらが読みやすいかという話題が出てくる。

私も含めて、多くの人が前者の方が読みやすいと感じると思う。

これも、特に誰かに習った訳ではなくて、本のサンプルコードを読んだり、人のコードを読んだりしているうちに、自然とそういうものだと身についたのだと思う。
だから、「なんで逆だとよくないのか説明してほしい」と言われると難しい。

本書を読むとちゃんと納得できる理由が書いてある。

やや余談だが、Javaでは以下のように、ヌルポを防御するためにexpectedな値の方を先に書く場合がある。

if("OK".equals(status)) {
    // 処理
}

これはこれで合理的な理由があるので良いのだが、初めて見たときは、なんで逆にしているんだろう?と疑問に思ったのを覚えている。

この書き方に違和感を覚えるというのも、評価する値を左側に書くというのが感覚レベルで身についていたからなんだろうなと思う。

7.2 if/elseブロックの並び順(p86)

このトピックでは、 if/elseで条件分岐をするときに、どの順番から書くとよいかということが議論されている。

私は、これも誰かに習った訳ではないが、経験的に「条件にnotが入ると可読性が下がるので、できるだけ避けるべき」ということは感じていたので、なるべく肯定条件で書くようにはしていた。

ただ、ロジックによっては、

if(has_error) {
  // エラー処理
} else {
  // 正常系の処理
}

のように、elseブロックの処理の方が正常系のロジックになる場合もある。

このような場合は、ifの先頭で判定するのが否定条件になったとしても、正常系の処理が先にくるようにした方がいいんじゃないかというようなことも考えていた。

この辺の考え方についても、本書にはいくつかの指針が提示されていた。
(考え方は大体合っていた。)

結論としては、「状況によって判断基準は変わってくる」とのことである。

8.1 説明変数、8.2 要約変数(p100)

ある程度プログミングをしている内に、変数には以下の2つの役割があるんだなと、自分の中で理解するようになった。

  1. 値に名前をつける。
  2. 式の結果を保存することで、同じ処理を何度も実行しないようにする&参照しやすいようにする。

1.に関しては、この逆の悪い例がいわゆる「マジックナンバー」だと思う。
マジックナンバー (プログラム) - Wikipedia

2. に関しては、例えば、患者が花粉症の症状があるか否かで処理を分岐したい時に、以下のようにいったん判定の結果を変数に格納しておく。

boolean hasSymptoms = patient.hasHayfever() && (month == 2 || month == 3)

こうすることで、同じ判定結果がコードの中で何回か必要になった場合に、hasHayfever()を何度も実行しなくてよいし、複雑な条件式を何度も書かなくてよいので、DRYなコードになる。

今日のコンピュータの性能であれば、よっぽど重い処理じゃなければ、処理が複数回実行されることでパフォーマンスに無視できないレベルの影響が出ることはないと思うので、「コードがDRYになる」の方が主要なメリットなのではないかと思う。

前置きが長めになったが、本書の用語に照らし合わせると、1の役割にあたるのが「説明変数」、2の役割にあたるのが「要約変数」ということになる。

上に書いたように、この2つの用語を知らなくても、ある程度コードを書いていれば、変数にはこういう役割があるんだなということは、感覚的にわかるようになると思うが、用語を与えられることで、

  • 感覚的に理解していたことに名前をつけて体系的に理解できるようになる。
  • レビューなどの場で、「ここは条件式が複雑だから『リーダブルコード』に出てくる「要約変数」にした方がいいと思うよ」というように、端的な言葉でコミュニケーションできるようになる。

などのメリットがあると思う。

10章 無関係の下位問題を抽出する

この章では全体として、ある関数の中で、処理の抽象度が周りのロジックと比べて低い部分(下位問題)を抽出して、別の関数に切り出すというプラクティスについて扱っている。

最初の例では、複数地点([経度,緯度のペア)の配列の中で、ある地点から最も近いものを探すロジックが出てくる。

この処理では、2つの地点の経度と緯度から距離を算出する部分のロジックが、とても複雑であり、周りのロジックと比べて抽象度が低い処理となっている。
この部分を別の関数に抽出することで、読みやすいコードになるということである。

これに関しても、あるメソッドの処理がfatになりすぎたら、処理をフェーズに分割して、別のclassやprivateメソッドに抽出するということは、ある程度の経験を積んだ頃には自然とやるようになっていた。

ただそれは、そうしないと可読性が下がって自分も困るからやっていただけで、一般的なリファクタリング手法であるということを意識しながらやっていた訳ではなかった。

今回、本書を読み直して、一般的なプラクティスの観点でも、間違ったことや横道にそれたことをしていた訳ではなかったんだなということを認識できたのはよかった。

また、p141の「あわせてよみたい」のコラムに、ケント・ベックの『Smalltalk Best Practice Patterns』の引用として紹介されている

メソッド内部の処理は同じ抽象度のレベルになるようにします

というアドバイスがとても勉強になった。

メソッド内部を複数のprivateメソッドに分割するということは、これまでもある程度できていたけど、分割するときの抽象度を揃えるということは意識していなかったので、今後はその辺も意識してコーディングできるようになりたいなと思った。

感想

全般的に感じたこととして、業務でエンジニアをやってきた中で、人のコードを読んだり、「ここはこうした方がいいんじゃないか」と考えたりして、自然と身についていたプラクティスに、ちゃんと名前が付けられて自分の中で整理されていく感じがとても気持ちがよかった。

数年前に読んだ時から評価が変わった理由の考察

今回、読み直して思ったのは、『リーダブルコード』以外の本にはあまり書かれていない貴重なトピックは、ある程度の品質が求められるコードをチームで書くようにならないとピンとこない、地味なトピックが多いなと思った。

学生でアルバイトでしかコードを書いたことがなかった当時は、その辺はアンテナにあまり引っかからなかったのかなと思った。

逆に『リーダブルコード』にも

  • 早期returnを使いましょう
  • 重複を除いたListが欲しい場合はSetを使いましょう

などといった、比較的テクニカルなトピックもあって、当時はそっちの方がアンテナに引っかかったのだと思う。

ただ、これらのテクニカルなトピックの方は、決して難しい内容を扱っている訳ではなく、『リーダブルコード』を読まなくても、他の本や記事にも書いてあったり、レビューで指摘されたりして自然と覚えられるようなことなので、結果的にあまり新しいことを得られなかったなという感想になったのだと思う。

Djangoでcreatesuperuserを自動化したいときに使えるオプション(--noinput)

概要

Djangoでプロジェクトを作成した後に、初期ユーザーを作成する際には

$ python manage.py createsuperuser

を実行する。

このコマンドは、デフォルトでは対話モードで実行されるので、自動化してスクリプトの中で実行したいときに面倒である。

私自身も、以前にDocker起動時にcreatesuperuserを実行してユーザーを作成したいことがあって、その際はcreatesuperuserを対話モードで実行する方法しか知らなかったので、expectコマンドで強引に作成していた。(できないことはなかった。)

kamatimaru.hatenablog.com

先日、公式ドキュメントに載っているやり方で、createsuperuserを宣言的に実行する方法があることを知ったのでメモ。

結論

前提

Django3.0以降であること

手順

①以下のように環境変数を定義する。

$ export DJANGO_SUPERUSER_USERNAME=admin
$ export DJANGO_SUPERUSER_EMAIL=admin@example.com
$ export DJANGO_SUPERUSER_PASSWORD=password

--noinputオプションをつけてcreatesuperuserを実行する。

$ python manage.py createsuperuser --noinput

これで、

  • ユーザー名: admin
  • メールアドレス: admin@example.com
  • パスワード: password

のユーザーが作成される。

説明

以下の公式ドキュメントに記載があるように、--noinputというオプションをつけると、createsuperuserを非対話モードで(=宣言的に)実行することができる。

docs.djangoproject.com

ただ、--noinputというオプション自体は元からあったようだが、このオプションを使う際には以下のように、--username--emailを一緒に指定してユーザーを作成する方法しか、Django3.0より前はなかったようである。

$ python manage.py createsuperuser --noinput --username=admin --email=admin@example.com

この方法では、パスワードは設定できないので、パスワードがemptyのユーザーが作成される。
※ 以下のissueをみると、そういう仕様らしい。
code.djangoproject.com

パスワードがemptyのユーザーでも問題ない用途であればよいのだが、例えばDjango Adminにログインしようとするとバリデーションで弾かれたりするなど、できないこともあるので、パスワードありのユーザーを作成したい場合もあると思う。

Django3.0で、--noinputをつけてcreatesuperuserを実行した際の各値を、環境変数に設定できるようになったので、パスワードありのユーザーを宣言的に作成できるようになった。

Changed in Django 3.0:
Support for using DJANGO_SUPERUSER_PASSWORD and DJANGO_SUPERUSER_ environment variables was added.

Python Developers Surveyの2020年版が公開された

少し前に、Python界にはPython Developers Surveyという年1の調査があるということを書いたが、先日、2020年版が公開されたようである。

www.jetbrains.com

2019年と比べると、以下がパッと目を引いた。

  • Fast APIが前回は名前がなかったが、今回は12%シェアがある。
  • PyCharmとVS Codeの差が前回よりも縮まっている。

ちゃんと比較したわけではないが、他はそんなに変わっていないような気がした。