ゼロから始める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 に変換します。 OSX や Linux であったとしても、終端が 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を解読していこうと思います。
解読
どこから解読していくか悩みますが、まずは一番最初の階層にあるファイルから解読していこうと思います。
.editorconfig
概要
.editorconfigは、EditorConfigという様々なエディターやIDE(総合開発環境)で同じプロジェクトに取り組んでいる開発者に対して、一貫したコーディングスタイルを維持するのに役立つ設定を記載しているファイルです。
Pluginを別途必要とする環境とそうでない環境があります。Pluginを必要としない環境では、.editorconfigファイルを置くだけで、設定が反映されます。
試しにインデントの数を変えて、PyCharmで設定が反映されているか確認したところ、問題なく反映されていました。


設定の詳細
# 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で。
このような感じで、1ファイルずつ投稿していこうと思います。 間違っている点などがあれば、ご指摘ください。 今回はここまで。
VMwareToolsのインストール方法 Linux版
環境
- VMware Workstation
- Kali 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をクリックする。

2、中央のGET PERSONALをクリックする。

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

4、保存したファイルと同じ階層にcdコマンドで移動し、次のコマンドを打つ。
# dpkg -i wing-personal7_7.1.0-2_amd64.deb
ちなみに、dpkgコマンドはdebファイルを扱うコマンドであり、-iオプションはインストールを意味する。
5、最後に依存関係のファイルがあるかもしれないため、次のコマンドを打つ。
# apt-get -f install
以上で終了。
wing-personalバージョンを端末で打つと起動できる。