マイクロソフトのテクニカルフェローで、TypeScriptのリードアーキテクトであるアンダース・ヘルスバーグ（Anders Hejlsberg）氏は、TypeScriptのコンパイラを始め各種ツール群をGo言語に移植する「Project Corsa」を実施中であり、結果として処理速度が約10倍速になることを明らかにしました。
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に － Publickey
ヘルスバーグ氏はTurbo Pascalの作者であり、その後もDelphi、C＃などの優れたプログラミング言語の開発に携わってきたことで知られています。
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に － Publickey
なぜC#やRustといった同氏が好む言語を使わないのか、という点に関して、同氏はさまざまな言語でプロトタイプを作った結果、すべてのプラットフォームで完全に最適化されたネイティブバイナリを生成できて、データレイアウトの細かな制御が可能で、ガベージコレクタによるメモリ管理が自動化され、優れた並列処理が可能などの理由によりGo言語を選択したと説明しています。
マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に － Publickey
⇧ 開発者やメンテナーからしたら「変更容易性」が担保できているんであれば問題ない気はしますが...
利用者からしたら、問題が起きた時に原因特定までに時間がかからないことが重要なので、エラーメッセージ設計とかはしっかりしていて欲しい気はしますな...
Ansibleでdocker-compose ps相当の機能を担うモジュールはまだないということなのか
「Ansible」の「モジュール」で「docker-compose ps」相当の機能が用意されていないわけがない、と信じていたのですが、
⇧ 見当たらないんですけど...
Docker関連の「Ansible」の「モジュール」一覧っぽいものが載っている公式のドキュメントのページを見てみるも、
⇧ ズバリというものが見当たらないんだが...
同じような疑問を抱えていらっしゃる方がおられたのですが、
⇧「docker_host_info」なる「モジュール」を利用して力業で実現するしかないという話らしい...
⇧ 戻り値に「docker container ls」相当の情報が取得できるとあるのだが、「docker-compose ps」相当の情報とは異なるのよね...
「Ansible」の「ansible.builtin.shell」という「モジュール」を利用して、シェルで「docker-compose ps」を実行してしまった方が良いのかしらね？
ネットの情報を漁っていた感じでは、
⇧ シェルスクリプトのコマンドを使ってる例が多いのよね...
結局のところ、「シェル芸」的な対応でいくしかないのか...
ちなみに、stackoverflowで言及されていた「モジュール」の「community.docker.docker_container_info」については、
⇧「戻り値」を見てみたのだけど、「State」の「Status」という項目が存在しないのよね...
それとも、単に「...」の省略されている部分で分からないだけで、存在する項目なのだろうか？
公式のドキュメントで「...」で省略するとか本当に止めて欲しいのだが...
いずれにしても、取得できる情報の中から「Dockerコンテナ」の「状態」についての情報を抽出して判定する処理を定義する必要がありそうなのだが...
そもそも、「Ansible」の「モジュール」で「docker-compose ps」相当の機能を実現できるものってあるんでしったけ？という話が、
⇧ 2020年頃に上がっていたようなのですが、2025年時点でも「docker-compose ps」相当の機能に対応した「Ansible」の「モジュール」は用意されていないらしい...
あとは、
⇧ 事後確認しか無いんよね...
事前確認の機能が無いのは何故なのか...
「Ansible」は何かと中途半端な感じがして仕方ないんだが...
中途半端であることを受け入れるという割り切りが必要なのかしらね...
「モジュール無い→独自に実装してみせるぜ→オレオレ実装の乱立→ワイの実装が秀逸じゃろうがい！」的な感じで、職人芸的な悪しき慣習に発展しかねない構造になってしまっているのは辛過ぎるんだが...
何よりも不思議なのは、「IaC（Infrastructure as Code）」的に必要とされるであろうと想定し得る機能が考慮されていなさ過ぎるのよね...
とりあえず、
- 要求定義
- ヒアリング（実現したいことは何か）
- 要求事項の整理
- 要件定義
- 要求事項について技術的に可能かどうかの判断
- 方式の検討・整理（コストなどの検討も）
のどちらが上手くいっていないのか分からないのだが、
Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理システムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている。
⇧ 元は手動で実現していた要求があるわけで、要件に落とし込んだ結果、スクリプトなどで実現していた部分を、「IaC（Infrastructure as Code）」的なアプローチで実現しようとしているのだから、求められる要求は変わっていない気がするんだが...
つまり、
- docker-compose ps
- docker-compose logs
などに相当する機能が要求として当然上がっているように思うんだが、何故に「Ansible」の「モジュール」で対応していないんだろうか？
状態を確認できないと、次の処理に進めようが無い気がしてしまうんだが、「IaC（Infrastructure as Code）」的な思想が分からないので何とも言えないけど...
何と言うか、
- 事前確認
- 処理に必要な情報が用意できているか
- 処理に必要な状態になっているか
- 処理実行
- 事後確認
- 処理実行が正常に実行されたか
- 処理実行によってエラーが発生していないか
が一連の流れになるのが一般的な気がするんだが、「確認」部分の機能が疎かになっている気がしてならない...
どんな業務でも、大まかな流れは変わらないような気がするんだけどなぁ...
「確認」部分の機能を疎かにする慣習って、IT業界だと一般的なんかな？
毎度モヤモヤ感が半端ない…
今回はこのへんで。
