修士論文共同研究 機械学習技術を応用した潜在的な乳がんの晩期再発バイオマーカーの推定
開発言語：Python
- Docker：コンテナ
- Makefile：コンテナ実行
- Jupyter Lab：解析環境
- miniconda：ライブラリ管理
- git：ローカルバージョン管理
- github：リモートバージョン管理
- notion：解析情報共有
- slack：連絡伝達・github 通知
本ソースコードを実行するには以下のツールが必要です。
本研究の開発環境は Docker のコンテナ上で実行できます。
Docker は Dockerfile に記述された設定に基づいて、『イメージの作成 ▷ コンテナの作成 ▷ コンテナの起動』の順序で実行することが多いです。
基本的には CLI（コマンドラインインターフェース）による実行が中心ですが、このコマンドを覚えるのも（引数などがあり）大変なため、Makefile で簡略化しました。
以下のコマンドで環境を構築できます。
各 make hogehoge 内で何をしているかは Makefile を確認してください。 Makefile 内で記述されている Docker のコマンドについては公式ドキュメントを参照してください。
# PLEASE RUN THESE COMMANDS UNDER THIS PROJECT REPOSITORY (./breast-cancer-analytics)
# 1. docker imageのbuild
# ※dockerで使用するubuntuイメージはcpuチップに依存します。Dockerfileを確認し、M1チップユーザーは1行目を、それ以外のユーザーは2行目をコメントアウトしてください。
make dbuild
# 2. docker containerのrun
# 1.で構築したイメージからコンテナを実行します。
make drun
# 3. containerのrestart
make drestart
# 4. 実行中のcontainerに入る
make dexec
# jupyterの実行（dockerのUbuntu環境内で実行）
make jupyter
不足しているライブラリは適宜 docker 環境内でconda install (or pip install)するか、Dockerfile 内に追加記述してください。
以下のコマンドや概念については理解してください。
git や github の基本的な概念になります。
- git add .
- git commit -m your_comment
- git push origin your_branch_name
- git pull origin main_branch_name
- git branch your_branch_name
- git checkout any_branch_name
- local と remote
- branch
- merge と conflict
git add .
git commit -m 'your_comment'
git push origin <remote_branch_name>
git pull origin <your_branch_name>
共同開発の際は、様々な人が開発をするため、その内容が様々に派生していきます。
１プロジェクトを全員で共有して同時に開発を進めると、旧バージョンで存在した機能が補修中となったために該当機能に依存した他の機能が停止してしまうことも起こりえます。
バグがあった場合、全員の進捗を戻す必要もあるでしょう。
そのため、個々人の開発領域を分けることで、上記の問題点を改善・低減することが重要になります。
git branchコマンドはこの開発領域の区分けを実現する機能です。
かならず自身の branch（開発領域）を設定してください。
git branch <branch_name>
git checkout <branch_name>
ノートブックで解析をすすめる上での規則を以下に記します。
視認性向上のため、なるべく厳守してください。
また、ノートブックにも定義した内容や、処理内容を、少なくともメモなどとして残してください。
他の人がコードを参考にしたり、レビューするときに、閲覧者の理解の妨げにならないようコードを整形することが求められます。
この時、個人個人でフォーマッタ方法が異なると意味がありません。
そこで今回は以下のツールを用いてコードの整形を実施します。
拡張機能を利用し、保存時に自動で整形されるようにすると良いでしょう。
- フォーマッタ: black
- コードチェッカー: flake8
コードを記述する際、様々な対象を命名するが、その名付けに規則を設けることでチーム内での理解が促進されます。
PEP8に則ったルールであるので、他の場面でも意識することを推奨します。
参考: https://qiita.com/naomi7325/items/4eb1d2a40277361e898b
| 対象 | ルール | 例 |
|---|---|---|
| パッケージ | 全小文字。アンダースコア（_）非推奨。 | numpy, pandas |
| モジュール | 全小文字。アンダースコア可。 | sys, os |
| クラス | 最初大文字＋大文字区切り | MyClass |
| 例外 | 最初大文字＋大文字区切り | MyError |
| 型変数 | 最初大文字＋大文字区切り | MyType |
| メソッド | 全小文字＋アンダースコア区切り | my_method |
| 関数 | 全小文字＋アンダースコア区切り | my_function |
| 変数 | 全小文字＋アンダースコア区切り | my_variable |
| 定数 | 全大文字＋アンダースコア区切り | MY_CONST |
jupyter notebook は全て./notebooks 以下に置くこと。
基本的な命名規則は以下だが、臨機応変に変更してください。
（カテゴリ番号）-（処理カテゴリ名）_（処理具体内容・対象）.ipynb
例. 0-download_data.ipynb
大区分 0. 分析以前の処理（データダウンロード）
- EDA
- 前処理
- モデル構築
- ハイパーパラメーターチューニング
- テストデータの半か性能検証・XAI の適用
- 生存時間解析
関数が何を行うのかがわかるような名前をつけてください。
また、基本命名規則に従い、全て小文字+アンダースコア区切りとしてください。
入出力がわかる関数共通使用のために、関数アノテーションを実施してください。
また、その関数が何を行うのか簡単なコメントを残すようにしてください。
例．
def function_compare(val1: int, val2: int) -> bool:
return val1 > val2
プロジェクトの構成をディレクトリで個人の思うままに管理すると不満に思う人も出てくるでしょう。
しかし、1 人 1 人の思想を反映するとディレクトリ構成を決めるだけでも大変です。
後々必要に迫られディレクトリ構成の変更を迫られたりするかもしれません。
そこで、広く使用されている構成を真似るためにCookiecutterというライブラリを用いました（https://github.com/cookiecutter/cookiecutter）。
Cookiecutter は OS に依存しないクロスプラットフォームで使用できるパッケージ構成管理テンプレートを展開する Python ライブラリです。
Python だけでなく JacaScript や Ruby など様々な言語で使用できますが、詳しくは公式のドキュメントを読んでください。
兎にも角にも Cookiecutter の形式に則り、今回の分析を実施していきます。
下記のツリー状の図は Cookiecutter で展開したディレクトリに配置するべきファイル等の説明です。
これらを参考に、ファイル・ディレクトリを操作する際は注意してください。
├── LICENSE
├── Makefile <- Makefile with commands like `make data` or `make train`
├── README.md <- The top-level README for developers using this project.
├── data
│ ├── external <- Data from third party sources.
│ ├── interim <- Intermediate data that has been transformed.
│ ├── processed <- The final, canonical data sets for modeling.
│ └── raw <- The original, immutable data dump.
│
├── docs <- A default Sphinx project; see sphinx-doc.org for details
│
├── models <- Trained and serialized models, model predictions, or model summaries
│
├── notebooks <- Jupyter notebooks. Naming convention is a number (for ordering),
│ the creator's initials, and a short `-` delimited description, e.g.
│ `1.0-jqp-initial-data-exploration`.
│
├── references <- Data dictionaries, manuals, and all other explanatory materials.
│
├── reports <- Generated analysis as HTML, PDF, LaTeX, etc.
│ └── figures <- Generated graphics and figures to be used in reporting
│
├── requirements.txt <- The requirements file for reproducing the analysis environment, e.g.
│ generated with `pip freeze > requirements.txt`
│
├── setup.py <- makes project pip installable (pip install -e .) so src can be imported
├── src <- Source code for use in this project.
│ ├── __init__.py <- Makes src a Python module
│ │
│ ├── data <- Scripts to download or generate data
│ │ └── make_dataset.py
│ │
│ ├── features <- Scripts to turn raw data into features for modeling
│ │ └── build_features.py
│ │
│ ├── models <- Scripts to train models and then use trained models to make
│ │ │ predictions
│ │ ├── predict_model.py
│ │ └── train_model.py
│ │
│ └── visualization <- Scripts to create exploratory and results oriented visualizations
│ └── visualize.py
│
└── tox.ini <- tox file with settings for running tox; see tox.readthedocs.io
Project based on the cookiecutter data science project template. #cookiecutterdatascience