READMEの作成

[book000]

• README.md
• README-ja.md

[book000]

• Puppeteerのようなヘッドレスブラウザによるスクレイピングではなく、純粋なHTTPリクエストとHTMLパーサーを用いたスクレイピングライブラリを開発する (GitHubにあるリポジトリを見る限り大多数がpuppeteerによるスクレイピング)
• 原則 READ ONLY。課題の提出や出席の提出などの機能は実装せず、不適切な利用をされることを防ぐ。
• あくまで私の大学のために作っているライブラリ。他の大学におけるUNIPAでの動作保証はできないし、私には動作の検証もできない。使うにあたってはそれらを理解した上で利用してほしい。不具合を見つけた場合は出来る限りプルリクエストでの修正をお願いしたい(issue立てられても環境が違えば検証できないことも)
• そもそも、動作保証は一切ない。
• サポート期限は2023/03まで。以降はアーカイブ

[book000]

contributing.mdかなあって内容だけど

• GitLab Flow likeなブランチ構造とフローを用いて開発を行う
  • Git Flowを用いない理由: 基本的に1人開発で、不必要に複雑なブランチ管理をする必要性がない。むしろ複雑にする方が本来のコーディングに割ける時間がなくなってしまう
  • GitHub Flowを用いない理由: feature/*ブランチからプルリクを上げる先のブランチ(master)が直接そのままリリースブランチになってしまうので、細かなリリースが発生してしまう。renovateによる自動依存パッケージ更新を想定しているので、細かく一度一度でリリースされてしまうのは厄介
  • GitLab Flowを用いる理由: masterへのマージで即刻リリースして構わない(リリースを調整する必要がない)、細かいリリースが発生せず、まとめたリリースを発行できる。
• 本リポジトリでは、GitLab Flowのproductionがmaster、pre-productionがdevelop、feature/*はそのままという形になる
• すべてのfeature/*はdevelopから派生。feature/*で開発を行い、developに対してプルリク・マージを行う。この際全てのCIが必ず通る必要がある
• developからmasterへのプルリクはgit-pr-releaseを用いて自動で作成される。適当なタイミングでレビュー・マージを行う
  • developの更新に合わせてTestPyPIとGitHub Releaseにてpre-releaseが自動発行される
• masterへのプッシュ時にPyPIとGitHub Releaseにて本リリースが行われる。同時にmasterからdevelopに対して自動的にブランチのSyncプルリクが行われる → 本リリース直後はmasterとdevelopは同一になる
• Pycharmにて開発。コミット時にunittestを実施
• CIでQodana、mypy、flake8のチェックを行う。型付けをきちんと行う