ゼロから始めるDjangoソースコード解読 part4

解読

.pre-commit-config.yaml

概要

Gitには、pre-commitフックというコミット時に特定のスクリプトを実行する機能があります。 既にGitHubリポジトリにいくつかのチェック用コードが存在しており、それらを指定することで チェックが通らない場合は自動でコードを修正したり、Commitを実行しないようにすることができます。 .pre-commit-config.yamlには、どのチェック項目を適用するかなどを設定します。

詳細

repos:
  - repo: https://github.com/PyCQA/isort
    rev: 5.6.4
    hooks:
      - id: isort
  - repo: https://gitlab.com/pycqa/flake8
    rev: 3.8.4
    hooks:
      - id: flake8
  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: v7.16.0
    hooks:
      - id: eslint
.pre-commit-config.yamlのオプション
項目 内容
repos リポジトリごとの設定を格納するためのリスト
repo 使用したいフックスクリプトリポジトリを指定。
rev repoで指定したリポジトリのバージョンもしくはタグを指定
hooks 使用するフックを格納するためのリスト
id 使用するフックを指定
フックの説明
項目 内容
isort pythonのimportの順番をチェックする。自動で整形してくれる。
flake8 pep8のチェック、pyflakesのチェック、及び循環的複雑度をチェックできるラッパー。様々な拡張機能が存在する
eslint JavaScript のための静的検証ツール

AUTHORS

概要

Django開発に携わった人の一覧。

CONTRIBUTING.rst

概要

Djangoをよりよくするために、バグ修正やコードパッチ、ドキュメントの改善を手伝ってくれる方のために、案内を記載してある。

終わりに

pre-commitは普通に業務に使える内容だったので、早速取り入れようと思う。

AUTHORSとCONTRIBUTING.rstはほとんど見る機会はないだろうから、頭の片隅に覚えておければいいかな。

それではまた次回。

ゼロから始めるDjangoソースコード解読 part3

解読

.gitattributes

概要

git全体の設定をする場合、以下のようにconfigオプションを使って設定することができます。

git config --global ~~~

リポジトリごとに設定したい場合は、.gitattributesに設定を記載します。djangoの.gitattributesファイルでは、主に改行コード周りの設定と、マージする際の設定が記載されています。

詳細

# Normalize line endings to avoid spurious failures in the core test suite on Windows.
*html text eol=lf
*css text eol=lf
*js text eol=lf
tests/staticfiles_tests/apps/test/static/test/*txt text eol=lf
tests/staticfiles_tests/project/documents/test/*txt text eol=lf
docs/releases/*.txt merge=union


項目 内容
text=auto gitが最善と判断する方法でファイルを処理する
text eol=crlf チェックアウトの際常に行終端を CRLF に変換します。 OSXLinux であったとしても、終端が CRLF でなければならないファイルにはこれを使用する必要があります。
text eol=lf チェックアウトの際常に行終端を LF に変換します。 Windows であったとしても、終端が LF でなければならないファイルにはこれを使用する必要があります。
binary 指定されているファイルがテキストではなく、変更を試みるべきではないと判断します。(バイナリファイルなどは変換されるとエラーになってしまうため)
merge=text テキストファイルとしてマージする。コンフリクトした場合、場所を教えてくれる。
merge=binary バイナリファイルとしてマージする。コンフリクトした場合、そのファイルを残す。
merge=union テキストファイルとしてマージする。コンフリクトした場合、どちらの変更も残すように適当に変更してくれる。

.gitignore

概要

.gitignoreに設定を記載することで、gitで管理するファイルを制限することができる。

詳細

# If you need to exclude files such as those generated by an IDE, use
# $GIT_DIR/info/exclude or the core.excludesFile configuration variable as
# described in https://git-scm.com/docs/gitignore

*.egg-info
*.pot
*.py[co]
.tox/
__pycache__
MANIFEST
dist/
docs/_build/
docs/locale/
node_modules/
tests/coverage_html/
tests/.coverage
build/
tests/report/
項目 内容
* /以外の0個以上の任意の文字列
** 0個以上のファイルやフォルダ
[0-9] 0~9までの数字一文字
[co] cかo一文字

終わりに

今回はgit関係のファイル二つを紹介しました。

ここら辺はもともと知っている方も多いと思います。

次回は、pythonのpre-commitというものを紹介しようと思います。(初耳のツール)

それではまた次回に。

ゼロから始めるDjangoソースコード解読 part2

あいさつ

ゼロから始めるDjangoソースコード解読 part2になります。 今回も張り切ってソースコードを読み解いていきます!

解読

.eslintignore

概要

ESLintという、コードの一貫性を高めたり、ECMAScript / JavaScriptコードで見つかったバグを回避したりするためのツールがあります。

.eslintignoreは、ESLintの対象から除外したいファイルやディレクトリを指定するためのファイルです。(gitでいう.gitignoreのようなもの)

詳細

**/*.min.js
**/vendor/**/*.js
django/contrib/gis/templates/**/*.js
docs/_build/**/*.js
node_modules/**.js
tests/**/*.js


ワイルドカードの説明

項目 説明
* /以外の0文字以上の文字列にマッチ
** 0個以上のファイル or ディレクトリにマッチ
! 否定


設定の説明

項目 説明
**/*.min.js .min.jsで終わるファイルをすべて無視する
**/vendor/**/*.js すべてのvendorフォルダ以下に存在する.jsで終わるファイルを無視する
django/contrib/gis/templates/**/*.js django/contrib/gis/templatesフォルダ以下に存在する.jsで終わるファイルを無視する
docs/_build/**/*.js docs/_buildフォルダ以下に存在するすべての.jsファイルを無視する
node_modules/**.js node_modulesフォルダ内(それ以下の階層を除く)に存在する.jsで終わるファイルを無視する
tests/**/*.js testsフォルダ以下に存在するすべての.jsファイルを無視する

「node_modules/**.js」だけは、「node_modules/*.js」との違いが解りませんでした。書き間違えなのか、何か意味があるのか。。

.eslintrc

概要

ESLintの設定ファイル。ルールを設定して、違反部分は警告するなどすることでコードに一貫性を持たせることができる。

詳細

{
    "rules": {
        "camelcase": ["off", {"properties": "always"}],
        "comma-spacing": ["error", {"before": false, "after": true}],
        "curly": ["error", "all"],
        "dot-notation": ["error", {"allowKeywords": true}],
        "eqeqeq": ["error"],
        "indent": ["error", 4],
        "key-spacing": ["error", {"beforeColon": false, "afterColon": true}],
        "linebreak-style": ["error", "unix"],
        "new-cap": ["off", {"newIsCap": true, "capIsNew": true}],
        "no-alert": ["off"],
        "no-eval": ["error"],
        "no-extend-native": ["error", {"exceptions": ["Date", "String"]}],
        "no-multi-spaces": ["error"],
        "no-octal-escape": ["error"],
        "no-script-url": ["error"],
        "no-shadow": ["error", {"hoist": "functions"}],
        "no-underscore-dangle": ["error"],
        "no-unused-vars": ["error", {"vars": "local", "args": "none"}],
        "no-var": ["error"],
        "prefer-const": ["error"],
        "quotes": ["off", "single"],
        "semi": ["error", "always"],
        "space-before-blocks": ["error", "always"],
        "space-before-function-paren": ["error", {"anonymous": "never", "named": "never"}],
        "space-infix-ops": ["error", {"int32Hint": false}],
        "strict": ["error", "global"]
    },
    "env": {
        "browser": true,
        "es6": true
    },
    "globals": {
        "django": false
    }
}

オプション

項目 説明
rules 様々なルールを設定することができる。詳しくはこちら(https://eslint.org/docs/rules/)
env 実行環境の設定を行うことができる。例:browser: ブラウザで実行される、es6: ES6が使用されているなど
globals グローバル変数が書き換え可能かどうか設定できる。falseの場合、グローバル変数の書き換えができなくなる

ESLintなんて存在すら知りませんでした。IT業界は勉強すればするほど勉強不足を思い知らされる気がするのは私だけでしょうか。。

今日はこの辺で。

ゼロから始めるDjangoソースコード解読 part1

導入

突然ですが、プログラムを書いている際に

「どんなソースコードが綺麗なの?」、「ファイルの構成ってこれでいいの?」

と思ったことはないでしょうか?私はいつも思っています←(開発経験1年目)

ですが、そういった記事をネットで調べようとしても意外と載っていないのが現状です。

そこで、手っ取り早く調べるにはどうすればいいか。そう、有名なソースコードを読めばいいのです!

有名だからといって、書かれていることがすべて正しいというわけではないとは思いますが、開発経験1年の私よりは遥かに綺麗なソースコードだと断言できます。

なので、1からソースコードを読み解いていき、これからの開発に役立つ知識をためていこうと思います。

私自身プログラミング初心者なので、同じ初心者にもわかりやすく書いていければと思います。

解読するソースコード

私はpythonを主に使用しているので、pythonフレームワークで有名なdjangoを解読していこうと思います。

github.com

解読

どこから解読していくか悩みますが、まずは一番最初の階層にあるファイルから解読していこうと思います。

.editorconfig

概要

.editorconfigは、EditorConfigという様々なエディターやIDE(総合開発環境)で同じプロジェクトに取り組んでいる開発者に対して、一貫したコーディングスタイルを維持するのに役立つ設定を記載しているファイルです。

EditorConfig

Pluginを別途必要とする環境とそうでない環境があります。Pluginを必要としない環境では、.editorconfigファイルを置くだけで、設定が反映されます。

試しにインデントの数を変えて、PyCharmで設定が反映されているか確認したところ、問題なく反映されていました。

f:id:id_Teto:20210323231224p:plain
インデント数:4

f:id:id_Teto:20210323231253p:plain
インデント数:16

設定の詳細

# https://editorconfig.org/

root = true

[*]
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true
end_of_line = lf
charset = utf-8

# Docstrings and comments use max_line_length = 79
[*.py]
max_line_length = 119

# Use 2 spaces for the HTML files
[*.html]
indent_size = 2

# The JSON files contain newlines inconsistently
[*.json]
indent_size = 2
insert_final_newline = ignore

[**/admin/js/vendor/**]
indent_style = ignore
indent_size = ignore

# Minified JavaScript files shouldn't be changed
[**.min.js]
indent_style = ignore
insert_final_newline = ignore

# Makefiles always use tabs for indentation
[Makefile]
indent_style = tab

# Batch files use tabs for indentation
[*.bat]
indent_style = tab

[docs/**.txt]
max_line_length = 79

[*.yml]
indent_size = 2


root設定

root = true

これは、.editorconfigが存在する階層がrootディレクトリかどうかを決める設定です。

EditorConfig Pluginは、あるファイルを開いた際に、そのファイルより上の階層に.editorconfigが存在するかどうかを探しに行きます。

trueに設定した場合、それ以上上の階層には探しに行かなくなります。

例:以下のような階層の場合、sample2/.editorconfigでroot=falseに設定していると、sample.pyを開いた際にsample1フォルダの.editorconfigまで読み込んでしまいます。

- sample1
        | - .editorconfig
        | - sample2
                | - .editorconfig
                | - sample.py


ファイル指定

[*]
[*.html]
[docs/**.txt]

これらは、対象とするファイルをワイルドカードで指定しています。

項目 説明
* パス区切り文字(/)を除く任意の文字列に一致します
** 任意の文字列に一致します
? 任意の1文字に一致します
[name] 名前の任意の1文字に一致します
[!name] 名前に含まれていない任意の1文字に一致します
{s1,s2,s3} 指定された(コンマで区切られた)任意の文字列に一致します(EditorConfig Core 0.11.0以降で使用可能)
{num1..num2} num1とnum2の間の任意の整数に一致します。ここで、num1とnum2は正または負のいずれかになります。


その他オプション

indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true
end_of_line = lf
charset = utf-8
max_line_length = 119
項目 説明
[*] すべてのファイルを対象とする , .py, *.{less,css,scala}などのワイルドカード
indent_style インデントの単位をタブにするかスペースにするか tab, space
indent_size 1回のインデントのサイズ 2,4,8
insert_final_newline ファイル末尾に空行を挿入するか true, false
trim_trailing_whitespace 行末尾のホワイトスペース(空白文字)を削除するかどうか true, false
end_of_line 改行コードの指定 cr, lf, crlf
charset 文字コードの指定 latin1, utf-8, utf-8-bom, utf-16be or utf-16le
max_line_length 一行に記載できる最大の長さを指定できる 正の整数、off


それ以外にも、オプションがあります。詳しくはEditorConfigのWikiで。

github.com


このような感じで、1ファイルずつ投稿していこうと思います。 間違っている点などがあれば、ご指摘ください。 今回はここまで。

VMwareToolsのインストール方法 Linux版

環境


1、まず右上のアイコンでCD/DVDデバイス仮想マシンと接続されていることを確認する。


2、次に端末を開き次のコマンドを実行。

# mount

その中に/dev/cdrom on /mnt/cdrom type iso9660と書いてあれば既にマウント済み。

3、マウントされていない場合、次のコマンドを実行。

# mkdir /mnt/cdrom
# mount /dev/cdrom /mnt/cdrom
#ls /mnt/cdrom 

ここで、lsコマンドを実行した際に、VMwareTools-XXXX.tar.gzのようなファイルが存在していればOK。(Xはバージョン)
存在しておらず、mountコマンド時に既にマウントされていますといったような警告文が出た場合、次のコマンドを実行。

警告文→mount: /mnt/cdrom: /dev/sr0 already mounted on /mnt/cdrom.
# umount /dev/sr0

こうすることでマウントが解除されたため、再度mountコマンドを実行すればいけるはず。

4、作業ディレクトリを適当な場所(/tmpなど)に移動して次のコマンドを実行。

# tar zxpf /mnt/cdrom/VMwareTools-XXXX.tar.gz

5、最後に、先ほどのコマンドで生成されたvmware-tools-distribディレクトリに移動し、次のコマンドを実行。

# ./vmware-install.pl

そうすると、インストールが始まるためとりあえずは途中止まったらenterを押していけば大丈夫。詳しい設定をしたい場合は調べたほうがいい。

6、最後にマウントを解除する。

# umount /dev/cdrom

これで作業終了。

Python環境におけるWingIDEの導入

今回はkali linux上での構築なので、pythonはすでに入っています。
念のため、バージョンを確認。

# python --version
Python 2.7.15+

入ってる入ってる。

本題のWingIDEをホームページからダウンロードする。
http://www.wingware.com

1、右上のDownloadをクリックする。
f:id:id_Teto:20190827230018p:plain


2、中央のGET PERSONALをクリックする。
f:id:id_Teto:20190827230349p:plain


3、右側のUbuntu/Debian Package 64-bitをクリックする。その際、ウインドウが出てきた場合はSave fileとしてファイルを保存する。
f:id:id_Teto:20190827231044p:plain


4、保存したファイルと同じ階層にcdコマンドで移動し、次のコマンドを打つ。

# dpkg -i wing-personal7_7.1.0-2_amd64.deb

ちなみに、dpkgコマンドはdebファイルを扱うコマンドであり、-iオプションはインストールを意味する。

5、最後に依存関係のファイルがあるかもしれないため、次のコマンドを打つ。

# apt-get -f install

以上で終了。
wing-personalバージョンを端末で打つと起動できる。