これまで観測誤差だと片付けられてきた、宇宙に関する理論と実際の観測記録の間にある食い違いが、ジェイムズ・ウェッブ宇宙望遠鏡といった最新鋭の観測技術により誤差ではなかったことが判明しつつあります。
長年にわたり、世界中の天文学者の間で論争となってきたこの矛盾の全容が明らかになり、人類が既存の宇宙観の再考を余儀なくされる時が目前に迫っていると、専門家が提唱しました。
現行の宇宙論の中で最も有力な標準モデルである「ΛCDMモデル」では、宇宙は68.3％のダークエネルギーと26.8％のダークマター、そして4.9％の通常の原子で成り立っているとされています。これは、ビッグバンの残光とも呼ばれている宇宙マイクロ波背景放射(CMB)の詳細な観測データから導き出された非常に正確な結果です。
ところが、近年に入ってこのモデルと矛盾する観測結果が報告されるようになり、長い間かけて築き上げられてきた理論の妥当性が揺るがされる事態となっています。
論争の渦中にあるのが、宇宙の膨張速度を表すハッブル定数です。
理論的には、ハッブル定数の値は67.4km／s／Mpc(キロメートル毎秒毎メガパーセク)ですが、ハッブル宇宙望遠鏡で宇宙の灯台とも呼ばれているセファイド変光星までの距離を測定して計算すると、値は73km／s／Mpcとなります。
この誤差は8％とわずかですが、統計的には無視できない違いです。
⇧ 8%って、1割に近い値を僅かとみなす感覚が理解できんのだけど...
学者の間で「緊張(テンション)」と呼ばれるこの矛盾した結果は、これまで「セファイドの光と他の星の光が合わさったことで観測結果に誤差が生じたのかもしれない」と説明されてきました。
しかし、目的の天体とそれ以外の光を正確に見分けることができるジェイムズ・ウェッブ宇宙望遠鏡での観測により、ハッブル宇宙望遠鏡の観測結果は間違いではなかったことが確かめられました。
⇧ 最早、観測が、事実ではなく思い込みが入り混じった推測でしか無かったことが証明されてしまったわけですな。
まさに、
An implicit bias or implicit stereotype is the pre-reflective attribution of particular qualities by an individual to a member of some social out group.
Implicit bias training (or unconscious bias training) programs are designed to help individuals become aware of their implicit biases and equip them with tools and strategies to act objectively, limiting the influence of their implicit biases.
Some researchers say implicit biases are learned stereotypes that are automatic, seemingly associative,unintentional, deeply ingrained, universal, and can influence behavior.
⇧ 物理学会が 「無意識のバイアス」に陥っていたということですかね。
そもそも、観測というアプローチとして、
ヘンペルのカラス （英: Hempel's ravens） とは、ドイツのカール・ヘンペルが1940年代に提出した、帰納法が抱える根本的な問題（「帰納法の問題」）を喚起する問題である。「カラスのパラドックス」とも呼ばれるが、パラドックスとして扱うべきかどうかには異論もある。
「AならばBである」という命題の真偽は、その対偶「BでないものはAでない」の真偽と必ず同値となる。
全称命題「全てのカラスは黒い」という命題はその対偶「全ての黒くないものはカラスでない」と同値であるので、これを証明すれば良い。
そして「全ての黒くないものはカラスでない」という命題は、世界中の黒くないものを順に調べ、それらの中に一つもカラスがないことをチェックすれば証明することができる。
そして「全ての黒くないものはカラスでない」という命題は、世界中の黒くないものを順に調べ、それらの中に一つもカラスがないことをチェックすれば証明することができる。
こうした事実は、科学の分野における命題には、実験や観察といった経験によって誤りであることが証明される可能性（反証可能性）があることを示している。
⇧ 上記の問題が不可避となりそうな気もする。
ただ、
その奇妙さ
宇宙には無限に「黒くないもの」があるとすれば、実際にヘンペルの論法を証明に用いることはできなくなる。「黒くないものはカラスでない」ことを証明するために「黒くないもの」を順に調べようとしても、その作業は永遠に終わらないからである。
⇧ 作業が永遠に終わらないであろうと言われているであろうが、論争によると、
『これまでの宇宙観測方法が誤りであった可能性がある』
という新たな気付きを得ることができたという点では、「ヘンペルのカラス」的なアプローチが無意味では無いと言えるのかね？
まぁ、
これまで、生物種総数の推定値には、300万～1億と大きな幅があった。現在の生物分類体系では、生物を下位から上位に向かって、種、属、科、目、綱、門、界の階層で分類し、約125万種がデータベースに登録されている。
今回の研究は、この登録された生物種を分析し、種と上位階層との間の数値的パターンを突き止めたことで、より正確な生物種数を算出できたという。
報告書によると、870万種のうち、動物が777万種、植物が29万8000種、菌類が61万1000種と推定。また、650万が陸上種で220万が海洋種だという。
⇧ 地球上ですら未知のことが多過ぎるからして、況や宇宙においてをや。
この推定方法も誤りである可能性はあると思われるが、他に代替できそうなアプローチが出て来ない以上は、突き進むしかないと。
アプローチの選定の影響が大きいのは、どの業界も変わらないってことですかね。
Gitリポジトリのホスティングサービスと脆弱性診断サービス
ChatGPTに確認した感じでは、
| No | Gitリポジトリホスティングサービス | 管理している組織 | 脆弱性診断サービス | プランの内容 | |
|---|---|---|---|---|---|
| 無償 | 有償 | ||||
| 1 | GitHub | Microsoft | Dependabot | ※1 | ※2 |
| 2 | GitLab | GitLab Inc. | SAST, Dependency Scanning | ※3 | ※4 |
| 3 | Bitbucket | Atlassian | Bitbucket Cloud's built-in security features | ※3 | ※4 |
| 4 | Snyk | Snyk Ltd. | Snyk | ※5 | ※6 |
| 5 | Renovate | Community | Renovate | ※7 | ※8 |
| 6 | SourceForge | Slashdot Media | Custom integrations available | ※7 | ※8 |
| 7 | Azure DevOps | Microsoft | Azure Security Center | ※9 | ※10 |
| 8 | AWS CodeCommit | Amazon | AWS CodeGuru (for review) | ※7 | ※11 |
| 9 | Google Cloud Source Repositories | Cloud Build integration | ※3 | ※4 | |
| 10 | Oracle Cloud Infrastructure DevOps | Oracle | OCI DevOps integration | ※9 | ※10 |
※1 基本的な依存関係の脆弱性チェック
※2 特殊な機能はなし
※3 プライベートリポジトリ数に制限
※4 制限なし
※5 スキャン数に制限
※6 スキャン数無制限、追加機能
※7 無償で利用可能
※8 特に無し
※9 一部機能が無償
※10 フル機能使用
※11 追加の使用料が発生する場合がある
⇧ 上記のようなサービスが用意されている模様。
GitHubのDependabotとは
公式のドキュメントによると、
Dependabot は、依存関係の管理に役立つ 3 つの異なる機能で構成されています。
- Dependabot alerts — リポジトリで使っている依存関係に内在する脆弱性について通知します。
- Dependabot security updates — 使っている依存関係のうち、既知のセキュリティ脆弱性があるものを更新するための pull request を自動的に生成します。
- Dependabot version updates — 依存関係を最新に保つための pull request を自動的に発行します。
https://docs.github.com/ja/code-security/getting-started/dependabot-quickstart-guide
⇧ 3つの機能で構成されていますと。
GitHubのサービスにおける「Dependabot」の立ち位置はというと、
GitHubのセキュリティ機能について
GitHubは、リポジトリ内及びOrganizationに渡ってコードとシークレットをセキュアに保つのに役立つ機能があります。 一部の機能は、すべてのプランのリポジトリに使用できます。 その他の機能は、GitHub Advanced Security を使うエンタープライズに使用できます。 GitHub Advanced Security の機能は、GitHub のすべてのパブリック リポジトリでも有効になります。詳しくは、「GitHub Advanced Security について」を参照してください。
https://docs.github.com/ja/code-security/getting-started/github-security-features
⇧ GitHubのセキュリティ機能の内の1つらしく、公式のドキュメントを読み進めていくと、
- すべてのリポジトリで使用可能
- セキュリティ ポリシー
- Dependabot alerts およびセキュリティアップデート
- Dependabot version updates:
- 依存関係グラフ
- リポジトリのセキュリティの概要
- 無料のパブリック リポジトリで使えます
- セキュリティ アドバイザリ
- ユーザーに対するシークレット スキャンニング アラート
- ユーザーのプッシュ保護
- パートナーに対するシークレット スキャンニング アラート
⇧ といった感じで、セキュリティ系の機能が盛り沢山過ぎるのだが、
『すべてのリポジトリで使用可能』
ということで、GitリポジトリとしてGitHubを利用しているのであれば、活用していきたい機能ということになるかと。
GitHubを利用していない場合は、利用できませんと。
GitHubのDependabotの機能を有効にしてみる
というわけで、まずは、GitHubでDependabotの機能を有効にする必要がありますと。
⇧ 上記の手順の通りに進めます。
ブラウザでGitHubにログイン後、画面右上のアイコンを押下。
「Settings」を選択。
左サイドバーで「Security」>「Code security」を選択。
手順の選択肢の設定項目と、実際のGithub上の設定項目が噛み合わないが、以下と想定して、3つ選択。
| No | 手順 | GitHub上の設定項目 |
|---|---|---|
| 1 | Dependabot alerts | Dependabot alerts |
| 2 | Dependabot security updates | Dependabot security updates |
| 3 | Dependabot version updates | Grouped security updates |
チェックマークが付けば有効化されたということらしい。
GitHubのDependabotの機能を利用してみるが、自動で処理されるようにしたい。GitHub Actionsも併用すればOKだが...
GitHub上で「Dependabot」の設定が完了後に、リポジトリを確認しに行くと、
■リポジトリの「Security」タブ
■リポジトリの「Pull requests」タブ
⇧ 各タブのページに、「Dependabot」が情報を生成してくれており、
といった内容になっているらしい。
ただ、脆弱性の対応についてのpull requestも自動でマージして欲しいと思うのが人情、と言うか、提案された脆弱性の対応が適切かどうかの意思決定も任せたいというAIに責任転嫁させたいのが多忙過ぎる現代社会に生きる我々人類が採用したいアプローチだと言っても過言ではないのではなかろうか？
要するに、面倒なことはAIにお任せしたいのである。
だって、現代人は忙しいんだもの。
GitHubの公式のドキュメントによると、
⇧ GitHub Actionsを利用すれば可能らしい。
ただ、実際の業務においては、
⇧ 上記サイト様にありますように、GitHub Actionsで実行条件を精緻に検討する必要はありますと。
つまり、AIの提案は信用ならん、という立場に立たざるを得ないと。
ちなみに、ChatGPTに確認したところ、「Gitリポジトリホスティングサービス」と「利用可能なCI/CDツール」の対応については、
| No | Gitリポジトリホスティングサービス | 管理している組織 | 利用可能なCI/CDツール |
|---|---|---|---|
| 1 | GitHub | Microsoft | GitHub Actions, Travis CI, CircleCI, Jenkins |
| 2 | GitLab | GitLab Inc. | GitLab CI/CD |
| 3 | Bitbucket | Atlassian | Bitbucket Pipelines, Jenkins |
| 4 | Snyk | Snyk Ltd. | GitHub Actions, Jenkins |
| 5 | Renovate | Community | GitHub Actions |
| 6 | SourceForge | Slashdot Media | GitHub Actions, Jenkins |
| 7 | Azure DevOps | Microsoft | Azure Pipelines, Jenkins, GitHub Actions |
| 8 | AWS CodeCommit | Amazon | AWS CodePipeline, Jenkins, CircleCI |
| 9 | Google Cloud Source Repositories | Google Cloud Build, Jenkins, GitHub Actions | |
| 10 | Oracle Cloud Infrastructure DevOps | Oracle | Jenkins, GitHub Actions |
⇧ 上記のような表になるらしいが、適当なんだろうなぁ...
と言うわけで、個人的なGitHub上のリポジトリで試してみます。
GitHub上で適当なリポジトリを選択し、「Add file」のアイコンを押下し、「Create new file」を選択。
ファイル名を入力します。今回は「.github/workflows/dependabot-auto-merge.yml」のようなファイル名にしました。
GitHub Actionsで実行したい内容をymlファイルに入力し、「Comment change...」ボタンを押下。
■[リポジトリのルートディレクトリ].github/workflows/dependabot-auto-merge.yml
name: Dependabot auto-merge
on: # トリガー（GitHub Actionsのフローを実行する手段）
pull_request:
workflow_dispatch: # 手動実行を有効にする
schedule:
- cron: '0 0 * * 0' # 毎週日曜日の00:00 UTCに実行
permissions:
contents: write
pull-requests: write
jobs:
dependabot:
runs-on: ubuntu-latest
if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'ts0818/Hello'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@v2
with:
github-token: "${{ secrets.GITHUB_TOKEN }}"
- name: Enable auto-merge for Dependabot PRs
if: steps.metadata.outputs.update-type == 'version-update:semver-patch'
run: gh pr merge --auto --merge "$PR_URL"
env:
PR_URL: ${{github.event.pull_request.html_url}}
GH_TOKEN: ${{secrets.GITHUB_TOKEN}}
⇧ 上記のような内容にしました。
コミットのメッセージを入力し、「Commit changes」ボタンを押下。
リポジトリに追加されました。
「Actions」タブの左サイドバーに、ymlファイルで追加したフローが表示されており選択できるようになっていればOK。
ymlファイルで、「on:」の設定で「workflow_dispatch:」を追加していると、GitHub上から手動実行できるようになる模様。
一応、手動実行してみたところ、「1 workflow run」と表示されているので、GitHub Actionsのフローが実行できた模様。
ただ、「Pull requests」タブの件数が減っていないところを見ると、
『全てのpatchレベルの更新を自動マージする』
という条件に一致しない「Pull request」ということらしい。
とりあえず、「Dependabot」の脆弱性の自動対応はできてませんが、「GitHub Actions」デビューは果たせたということで。
「GitHub Actions」について、リポジトリ横断的に共通のフローを適用させたい場合、どうすれば良いんだろうか？
もし、GitHub Actionsのフローを定義するのが、リポジトリ毎にしかできないとすると、仮に100個のリポジトリがあった場合に、100個すべてにymlファイルを配置、且つ、「DRYの原則」に違反する重複する記述をせざるを得なくなり地獄だなと...
今のところ、
⇧ 上記サイト様にありますように、共通のフローを定義したymlファイルを配置する用のリポジトリを1つ用意する必要がありますと。
このあたりが限界といった感じですかね...
全てのリポジトリに対して「Dependabot」向けの共通的なフローを実行させたい場合は、「Dependabot」用の無意味な空レポジトリを作成する感じになってしまうのは致し方ないということですかね...
とりあえず、「GitHub Actions」の設定が分かり辛い...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
