日本の文部科学省（MEXT）による分析によって、日本の研究が世界の人々から注目される研究成果を出せなくなっていることが示されました。
報告書では、日本は中国と米国に次いで世界3位の研究開発費を投じているにもかかわらず、学術論文の上位10%に掲載される論文数が20年の間に4443本から3767本と15%も減少しており、韓国・スペイン・イランに次ぐ世界13位と大きく順位を落としました。
⇧ Oh, my gosh...
2002年から2018年の間に研究者たちが研究に費やした時間の割合を調べたところ、47%から33%と大幅に減少していたのです。
近年になり大学の研究者たちには、民間や学校教育などの社会的な場に積極的にかかわるよう、促し続けられていました。
もちろん大学の社会貢献は重要ですが、日本においては研究時間を大幅に削る結果になってしまいました。
さらに博士課程やポスドクと呼ばれる若手研究者の収入は就職組に比べて圧倒的に低く、任期制のために職の安定性もありません。
つまり日本では投資額をあまり増やさないまま、研究者たちの待遇を悪化させ、選択と集中の名のもとに資金の獲得レースを強い、短期的な成果を求める研究だけに資金が投じられているのです。
⇧ 分析の結果（日本の研究の国際的な競争力の低下）が正しいと仮定して、原因についての仮説も正しいのであるならば、確実に日本の政府（主に与党）による施策や大学側の取り組みが間違いだったことが明らかになったわけですな...
まぁ、IT業界においても、開発時間が取れないという構造があり、同様の問題を抱えているわけなのだが...
日本の政府（主に与党）の問題を先送りにする仕組みが限界を迎えつつあるような気はする...
「令和の百姓一揆」ではないですが、
一揆の史学における研究は、中世の一向一揆や土一揆などから深められたため、民衆の一揆として捉えられ、領主（支配者）から禁じられるべきもので、民集の結合や暴動であるというイメージで捉えられるようになったとの指摘がある。
⇧「1%弱」に該当するケースが起こっても致し方ないことを日本の政府（主に与党）は続けているわけですな...
「政治」に「利権」が入り込まない仕組みを作るしか無さそうなのだが、とりあえず、
- 「利権」を画策する不穏分子を監視する第三者機関（※1）を設立する
- 「施策」の契約内容は第三者機関のシステムでチェックする
- 「施策」に関わるステークホルダーは監視対象化におかれる（※2）
- 「利権」に関わるステークホルダーの言動を公開する
- 「利権」に関わったステークホルダーを裁判にかける
- 有罪の場合は、人権を剥奪の上、無期限強制労働の刑。（※3）
- 無罪の場合は、疑われる言動をしたとして、裁判に関わる第三者機関の活動費を全額負担させる
※1 第三者機関の活動は全て記録され、裁判の際の情報として使用される。第三者機関の活動にかかるコストは、政治家（主に与党）の給与から差し引かれる。政治家の給与で不足する場合は、税金で賄う。
※2 三世代まで継続して監視し、不正が発覚した時点で裁判にかけられる。
※3 一族郎党が、刑の対象。社会的に抹殺されるということ。
みたいな「SF（Science Fiction）」の世界線を導入するしか無いような気がする...
まぁ、日本の政治家（主に与党）が、当たり前の事ですらできないようなので、システムで不正を検出する仕組みを導入せざるを得ない感じなのよね...
莫大なコストがかかることにはなりますが...
後は、そもそもとして「施策」の「優先順位」付けができていないのよね...
「災害」の「復興」などは、即時に対応すべきとは思うのですが、「能登半島地震」の対応状況を鑑みるに、「優先順位」付けができているとは言い難い...
全てにおいて杜撰なのが誠に遺憾である...
「国会中継」以外の視える化として、「政府」が「国民」を監視するのではなく、「国民」が「政府」を監視できる仕組みが必要ですと。
AnsibleでGitHub AppのInstall Access Tokenを取得したいのだが...
一応、有志の方による「GitHub App」の「Install Access Token」を発行する「Ansible」の「モジュール」は存在するようなのですが、
⇧ 要件を見ると、「controller node」に「Python」の「モジュール」である「python-jwt」がインストールされている必要がありますと。
つまり、
⇧「Ansible」がインストールされている環境（「Playbook」が実行できる）に「python-jwt」がインストールされていなければならない...
で、「プロキシサーバー」を経由させたい時はどうするのか？
⇧ とあり、
- プレイ
- ブロック
- タスク
の粒度で一時的に「プロキシ」の設定を有効にできるっぽい。
「プレイ」、「ブロック」、「タスク」については、
⇧ 上図にあるように、「Playbook」の構成に関係してきますと。
「ブロック」については、
⇧ 前回の記事の時に出てきましたが、複数の「タスク」をまとめることができるものですな。
で、自分のケースにおいては、「GitHub App」の「Install Access Token」は「Dockerコンテナ」内で「git clone」する際に必要になってくるので、
⇧ 上記の「モジュール」で対象のホスト（「Managed nodes」に該当）で稼働している「Dockerコンテナ」にログインして、「git clone」する必要があるわけだ。
なので、最悪、「community.docker.docker_compose_v2_exec」の「シェルスクリプト」部分で、
⇧ 上記にある通り、
を実装する形にはなる。
当然のことながら、事前に、
- GitHubでGitHub Appを作成しておく
- GitHub Appで秘密キー（.pem）を生成しておく
- JWT（JSON Web Token）の生成、Install Access Tokenの発行に必要な情報を参照できる場所に配置しておく
をしておく必要はある。
話が脱線しましたが、相変わらず、「Ansible」の「モジュール」は、
- Controller node
- Managed node
のどちら側で情報を管理させたいのかが分り辛い...
とりあえず、「Ansible」で「GitHub App」の「Install Access Token」を発行する方式としては、
の4パターンになるのかなぁ...
一番最後のパターンは、たまたま、「GitHub App」の「Install Access Token」を発行するリクエスト処理が、アプリケーション（Python）の一部にあるから実現可能かもしれないという話なのだが、本来であれば、3パターンになるのかなぁ...
「Ansible」の「モジュール」が別の「モジュール」内から利用できれば良かったんですけどね...
つまり、「community.docker.docker_compose_v2_exec module」でログインした「Dockerコンテナ」の環境で「community.general.github_app_access_token lookup」の機能が利用できれば悩まなくても済んだのですが...
ちなみに、
⇧「シェル」から「python」の特定の関数を呼び出すことは理論上は可能らしい。
とは言え、開発したアプリケーション（Python）が、コマンド実行で呼び出されることを想定した作りになっていないからなぁ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
